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AVERTISSEMENT. 





De nouveaux enjeux pour la recherche 
& ses applications 


Ce document de synthèse publié par 

le PRC GRECO Programmation du CNRS 
est une nouvelle édition du rapport 
scientifique “Bilan et perspectives” de Juin 
1986, avec une actualisation des travaux 
et résultats. 

Il sera largement diffusé auprès des 
responsables de l'ensemble de la 
communauté scientifique, industrielle 

et Üniversitaire. 

Le PRC GRECO Programmation marque 
ainsi sa volonté de poursuivre une 
politique d'ouverture et de dialogue avec 
tous les acteurs de la recherche et du 
développement technologique. 


Le PRC (Programme de Recherches 
Coordonnées) : “Programmation 
avancée et outils pour l'intelligence 
Artificielle” est financé par le Ministère 
de la Recherche dans le cadre du 
programme national mobilisateur 

de la filière électronique. 
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LA REALISATION de cette 
nouvelle brochure présentant 
l'activité des équipes du GRECO 
Programmation fournit l'occasion 
de mesurer le chemin accompli 
par les chercheurs en deux ans. 
Ainsi d'importantes avancées ont 
été réalisées dans le domaine de 
la compréhension des liens entre 
logique mathématique et 
programmation laissant entrevoir 
une nouvelle génération de 
langages de programmation, pour 
lesquels l'écriture d'un programme 
et la preuve mathématique de sa 
correction seront intimement liées. 
Quel progrès pour la fiabilité des 
logiciels ainsi conçus! Ce progrès 
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ne fera que conforter les résultats déjà obtenus grâce aux spécifications algébriques, point fort des recherches 


du groupement, 


Dans le domaine de l'écriture de compilateurs pour les langages applicatifs et logiques, les résultats obtenus 
constituent une progression continue du savoir-faire. On peut maintenant rédliser des traducteurs efficaces, 
parfois commercialisés, permettant d'ouvrir des possibilités importantes pour tous les logiciels manipulant des 
données symboliques et des formalismes. 

La large diffusion des stations de travail graphiques a aussi grandement favorisé l'éclosion de nouvelles formes 
de programmation; ainsi la programmation orientée par les objets très populaire parmi les équipes de dévelop- 





pement de logiciel, pose des questions à la fois fondamentales et d'implé- 
mentation qui motivent les chercheurs du GRECO Programmation. 
L'algorithmique enfin, considérée comme une vieille discipline dans notre 
domaine en pleine effervescence, a trouvé de nouveaux champs d'inves- 
figation avec les problèmes posés par la représentation et la manipula- 
tion de figures géométriques. Un nouveau chapitre de l'informatique 
fondamentale est en train de s'écrire. 

Cette avancée remarquable de la connaissance scientifique en program- 
mation doit être étendue aux entreprises : industriels, SSIL, grands utilisa- 
teurs. Le GRECO Programmation s'est engagé dans un programme 
d'actions en direction des milieux professionnels en établissant de 
nouveaux liens entre le monde de la recherche et celui des entreprises. 
Une plus large diffusion des résultats a été réalisée grâce à la mise en 
place de structures de coopération; de nombreuses réalisations de 
logiciels commercidlisables ont été effectuées souvent dans des PME 
créées par des chercheurs issus du GRECO Programmation. 

Voici donc proposés dans cette brochure un certain nombre d'enjeux 
pour les années futures, enjeux à la fois dans le domaine des connais- 
sances fondamentales, mais aussi dans celui de la mise à disposition pour 
les concepteurs et utilisateurs de logiciels d'outils sûrs et efficaces. 


NOUVEAUX ENJEUX POUR LA RECHERCHE & SES APPLICATIONS & 


REMERCIEMENTS l'équipe de direction du GRECO Programmation 
| EI remercie fous ceux qui ont collaboré 
à la réalisation de cet ouvrage. 
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sous la direction de Michel Mouyssinat 
L'agence Ambodexter à Bordeaux 

en a réalisé le design et le suivi de fabrication 
AAG à Bordeaux en a assuré 

la photocomposition dans différents dessins 
de Futura et d'English Times 

ainsi que la photogravure 

Thierry Billé à Floirac a exécuté la maquette. 


Achevé d'imprimer le 8 septembre 1988 

sur les presses de l'imprimerie Sylvain à Bordeaux. 
Deuxième semestre 1988. 
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Présentation 





Michel Mouyssinat 
Chargé de mission 

aux adions industrielles 
GRECO Programmation 
Bordeaux 


Une trentaine 
d'équipes, 

250 chercheurs, 

des projets ambitieux. 


Dans le cadre de la mise en place du pro- 
gramme national mobilisateur de la filière 
électronique et de son soutien aux équipes 
françaises de recherche en informatique, le 
Ministère de la Recherche et de la Technolo- 
gie a décidé de créer au cours des années 
1984 et 1985, 7 programmes de recherche 
(PRC : Programmes de Recherches Coor- 
données), mobilisant des équipes du 
CNRS, des Universités, d’organismes 
publics ou privés autour de thèmes bien 
identifiés : (Intelligence Artificielle - Bases 
de données - Communication hommes- 
machines - Programmation Avancée et 
Outils pour l'intelligence Artificielle - 
Mathématique et Informatique - Informa- 
tique et Linguistique - Coopération, 
Concurrence, Communication et un 8° en 
1987 : Architecture. Ces programmes aux 
objectifs ambitieux marquaient une nou- 
velle étape importante pour la recherche 
française en informatique. 


Le PRC “Programmation Avancée et Outils 
pour l’Intelligence Artificielle” a été créé en 
1984 et organisé autour du GRECO Program- 
mation (GRECO : Groupement de Recher- 
ches Coordonnées du CNRS), formation du 
CNRS qui regroupait déjà un grand nombre 
d'équipes françaises parmi les plus avancées 
en informatique fondamentale et jouait 
depuis quelques années un rôle pilote au 
plan national et international. 


Le GRECO Programmation maintenant 
élargi au PRC réunit une trentaine d'équipes 
de recherche (CNET, CGE, IBM, INRIA, Ecole 
des Mines, Ecoles Normale et Polytechni- 
que, Universités, CNRS) et vise plusieurs 
objectifs : 

e enrichir les connaissances de ses équipes 
en poursuivant l'effort en faveur de l’équipe- 
ment informatique, en améliorant les 
moyens de communication entre les 
chercheurs et en menant une politique 
d'ouverture et de coopération vers d’autres 
partenaires (équipes étrangères, industriels, 
autres PRC), 

e faire sortir la programmation du stade arti- 
sanal et développer une théorie de plus en 
plus riche pour servir de cadre notamment 
au développement de programmes com- 
plexes, 

s réaliser des prototypes de logiciels à des 
fins d’expérimentation et pour acquérir un 
savoir-faire dans un domaine où la France 
accuse encore malheureusement un certain 
retard, 


du GRECO Programmation 


e former par la recherche les ingénieurs et 
techniciens de haut niveau que réclament 
les entreprises et donner à l’industrie les 
moyens d’anticiper les conséquences des 
profondes mutations technologiques, 
eélargir les rapports des équipes de 
recherche avec les entreprises industrielles 
pour échanger des connaissances, des 
savoir-faire, des expériences, valoriser les 
résultats des travaux de recherche et assurer 
leur transfert. 


Plusieurs axes 

de recherche 

sur Île thème : 
“Programmation 
avancée et outils 
pour l’intelligence 
artificielle” 


Le GRECO Programmation est dirigé par 
Robert CORI, Professeur; son siège est ins- 
tallé à l’Université de Bordeaux L. 


Une équipe de direction dont les membres 
sont choisis parmi les principaux responsa- 
bles des équipes, se réunit tous les deux mois 
pour mettre en œuvre sa politique : défini- 
tion de nouveaux projets, répartition des 
moyens... 


Le comité de direction se réunit une fois par 
an pour évaluer les résultats scientifiques 
obtenus et proposer les axes de développe- 
ment futurs. 


Les recherches sont organisées en projets et 
regroupées en quatre pôles : 

e les fondements logiques de la programma- 
tion, 

e génie logiciel : conception d’environne- 
ments de programmation. 

° Jangages et outils pour l'intelligence artifi- 
cielle et architectures de machines-langages, 
+ algorithmique 

Le lecteur trouvera une présentation géné- 
rale des pôles, réalisée par chacun des res- 
ponsables, qui précède les rapports relatifs 
aux différents projets. 


Le caractère fondamental de ces travaux 
place le GRECO en amont de nombreux 
développements de logiciels. En effet, les 
recherches menées par les théoriciens en 
logique, combinatoire, théorie des graphes, 
calcul formel, théorie des langages et des 
automates, etc. ont permis de définir denou- 
veaux cadres théoriques, de nouveaux 
modèles et corps de doctrine quiconstituent 
les fondements de l’ensemble des travaux 
actuels. Ils précèdent et sous-tendent les 
efforts de recherche de développement dont 
la finalité est de réaliser des produits. Hesten 
effet important de souligner qu’aujourd’hui 
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dans des domaines avancés de l’informati- 
que, comme par exemple celui des bases de 
données, du génie logiciel, ou de l’intelli- 
gence artificielle, les produits logiciels com- 
mercialisés implémentent de nombreux 
concepts très théoriques et mettent en 
œuvre des outils algorithmiques complexes : 
par exemple, les langages de 4° génération 
d'interrogation de bases de données s’ap- 
puient sur la notion d’algèbre relationnelle 
dont les premières notions sont introduitent 
en 1962, formalisées en 1970 : un certain 
nombre d’outils de génie logiciel réalisent 
des manipulations formelles de programmes 
sous la forme d’arbres et utilisent donc des 
objets dont les représentations et propriétés 
algorithmiques ont été largement étudiées 
par les théoriciens des graphes et de la com- 
binatoire ; le langage LISP créé en 1960, uti- 
lisé aujourd’hui dans les applications d’intel- 
ligence artificielle repose sur la théorie du 
lambda-calcul. 


Ce sont encore les approches formelles 
mathématiques qui permettent, en étudiant 
des techniques, de découvrir les mécanis- 
mes et objets qu’elles mettent en œuvre, 
pour mieux pouvoir les expliquer, les com- 
prendre et les maîtriser - parfois même elles 
conduiront à les automatiser, C’est ainsi, par 
exemple, que le développement des compi- 
lateurs est devenu aujourd’hui une tâche 
relativement simple et que des tentatives de 
production automatique de compilateurs 
sont en cours dans le cadre des travaux en 
métacompilation, 


Si les exemples sont nombreux qui mon- 
trent l'importance des recherches fonda- 
mentales, ils font également prendre cons- 
cience des lenteurs avec lesquelles s’opère 
leur transfert vers les applications. 


Ainsi, les recherches poursuivies au GRECO 
Programmation relèvent-elles de l’informa- 
tique fondamentale, mais celui-ci s’est aussi 
fixé comme règle de toujours valider l’en- 
semble des résultats théoriques dans le cadre 
de développements logiciels. Les différents 
projets ont donc conduit à de nombreuses 
réalisations de produits qui permettent ainsi 
en implémentant les nouveaux conceptsune 
meilleure diffusion des acquis de la recherche 
et un moyen de transfert à l’ensemble de la 
communauté scientifique. 


Pour assurer la promotion et une diffusion 
plus large de ces logiciels, le GRECO 
Programmation, bénéficiant de la dynami- 
que de ses propres équipes, mène une poli- 
tique d'ouverture et de coopération vers 
d’autres partenaires : équipes étrangères, 
autres PRC, industriels, 


De nombreux contacts, concrétisés le plus 
souvent par le séjour de chercheurs dans des 


laboratoires étrangers ont donné lieu à de 
fructueuses collaborations et certains projets 
de recherche sont menés en étroite liaison 
avec d’autres partenaires européens ou amé- 
ricains (MIT, York, Berkeley, Stanford, Edim- 
bourg, etc.) 


Cette politique de coopération, par un effet 
de synergie, a accéléré le développement des 
produits logiciels, suscité de nombreuses 
demandes d'utilisation, favorisé leur diffu- 
sion et leurs échanges, 


Leur évaluation, par les partenaires étran- 
gers, a permis en outre de conforter la posi- 
tion française, aussi bien sur le plan du 
savoir-faire en développement logiciel que 
dans le domaine de la recherche fondamen- 
tale, 

Le GRECO Programmation n’a pas pour 
objectif de capitaliser pour lui-même et ses 
partenaires les acquis importants de sa 
recherche, 


Il est très désireux au contraire de s’ouvrir 
davantage sur tous les acteurs de la 
recherche et du développement technologi- 
que, d’intensifier les relations avec les 
milieux professionnels et de développer plus 
largement de nombreuses collaborations, 


Les moyens du GRECO 
Programmation : 

le serveur national 
GEOCUB, Île réseaux 
des VAX, les stations 
de travail. 


Pour atteindre ses objectifs scientifiques, le 
GRECO Programmation s’est doté de 
moyens propres. Sa politique d'équipement 
informatique définie en comité de direction 
vise à acquérir la puissance nécessaire aux 
besoins de calcul et à maintenir un parc 
homogène au niveau national, compatible 
avec les matériels de ses partenaires étran- 
gers, 


Un réseau de VAX système UNIX constitue 
son infrastructure en moyens de calcul et 
de communication. Le serveur national 
GEOCUB installé à la direction du GRECO à 
lPUniversité de Bordeaux est un des nœuds 
de ce réseau. Il est un point d’accès aux 
réseaux européens et américains et bientôt 
au réseau EARN. 


Longtemps machine de développement 
pour l’ensemble des équipes, aujourd’hui 
équipées de stations de travail, reste le sup- 
port de la quasi-totalité des produits logiciels 
réalisés dans le cadre des projets ou importés 
des laboratoires étrangers. Il offre, de plus, 


des services de messagerie et de courrier 
electroniques qui facilitent les efforts de coo- 
pération des différentes équipes; celles-ci 
ont accès en outre à tous les moyens de cal- 
cul mis en place au sein des Universités et du 
CNRS; certaines d’entre elles pour répondre 
à des besoins plus spécifiques, sont équipées 
de stations de travail (SM90, SPS7, SUN). 


La montée en puissance des stations de tra- 
vail (SUN par exemple) et l'autonomie de 
plus en plus grande des équipes maintenant 
dotées de moyens propres, les rendent beau- 
coup moins dépendantes d’une machine 
centrale. Le GRECO Programmation reste 
cependant très fortement attaché à la fonc- 
tion de communication en interne et avec 
l'extérieur. Il étudie un projet d’intercon- 
nexion des sites équipés de matériels SUN et 
VAX dans un réseau national dont la mise en 
place devrait intervenir vers la fin l’année 
1988. 

Le GRECO Programmation entend rester un 
pionnier en matière de réseau et de commu- 
nication inter-sites et attache beaucoup 
d'importance à ce projet. 


L'ensemble des moyens financiers du 
GRECO Programmation est constitué par les 
dotations du CNRS et du Ministère de la 
Recherche et de l’Enseignement Supérieur 
dans le cadre de la filière électronique (6MF 
environ par an) qui viennent s'ajouter aux 
ressources propres de chacun des laboratoi- 
res de rattachement des différentes équipes. 


Les résultats obtenus 


Le GRECO Programmation a huit ans et les 
résultats obtenus sont importants. 


ACCROISSEMENT DES 
CONNAISSANCES EN INFORMATIQUE 
FONDAMENTALE 

L'importance des publications scientifiques 
dans les revues spécialisées internationales 
des équipes du GRECO Programmation, 
leurs participations nombreuses à des collo- 
ques, aux projets de recherche nationaux et 
internationaux, le nombre d’invitations dans 
les universités étrangères de ses chercheurs, 
la diffusion très large des logiciels dévelop- 
pés, révèlent l'importance et la qualité des 
travaux effectués, la place de ses équipes 
dans la communauté scientifique internatio- 
nale. 


FORMATION PAR LA RECHERCHE DES 
INGÉNIEURS ET TECHNICIENS DE 
HAUT NIVEAU 

Le GRECO Programmation est conscient de 
limportance d’une coopération étroite avec 
les Universités et les grandes écoles pour la 
formation par et à ia recherche et beaucoup 
de ses chercheurs et ingénieurs participent à 
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des enseignements. Il faut souligner, à cet 
égard, que les résultats unificateurs et sim- 
plficateurs mis au jour par la recherche 
constituent des modèles qui se prêtent beau- 
coup mieux au transfert de connaissances 
qu’une somme disparate de plusieurs appro- 
ches différentes des techniques informa- 
tiques. 

Ces formations initiales trouvent leurs pro- 
longements nécessaires par des actions de 
formation continue dans lesquelles les équi- 
pes du GRECO sont très fortement engagées. 


SAVOIR-FAIRE EN DÉVELOPPEMENT 
DE LOGICIELS COMPLEXES 
L'ensemble des projets de recherche des dif- 
férentes équipes du GRECO Programmation 
a conduit à de nombreuses réalisations de 
produits dont certains sont déjà commercia- 
lisés, d’autres à l’état de prototype. Ils sont 
tous accessibles sur le serveur GEOCUB ins- 
tallé à Bordeaux et le GRECO Programma- 
tion leur assure une large diffusion dans le 
cadre de la politique de coopération qu'il 
s’est définie. Il organise en outre de nom- 
breuses présentations de ces logiciels 
accompagnées de démonstrations, Celles-ci 
s'adressent surtout aux professionnels pour 
lesquels elles offrent un réel intérêt, car les 
concepts et schémas théoriques issus de la 
recherche sont ainsi rendus très facilement 
accessibles. De plus, leur implémentation 
démontre la faisabilité de ces nouveaux sys- 
tèmes et suggère de nombreux champs d’ap- 
plications. 


CONNAISSANCE D'UNIX ET DE SON 
ENVIRONNEMENT 

ILest important de rappeler que la quasi-tota- 
lité des développements logiciels est réalisée 
sur matériel système UNIX. Alors qu'UNIX 
est devenu aujourd’hui un nouvel enjeu 
dans la stratégie industrielle de nombreuses 
sociétés française, les équipes du GRECO qui 
en ont acquis une parfaite maîtrise contri- 
buent très largement à mieux faire connaître 
ce système et son environnement dans le 
cadre des activités de recherche et des 
actions de formation (stages de formation 
continue, enseignement à l’Université ou 
dans les grandes écoles). 


TRANSFERT DES RÉSULTATS DE 
RECHERCHES 

Les nouveaux langages, outils et méthodolo- 
gies, les nouvelles architectures de machi- 
nes, réalisés dans le cadre des activités de 
recherche, définissent les futurs standards et 
préfigurent les systèmes informatiques de la 
fin de ce siècle. L'importance, au niveau 
international, des grands courants scientifi- 
ques qui traversent la recherche et entraf- 
nent ces travaux, laisse en effet présager de 
nombreuses retombées dans le monde 
industriel. 


Présentation du GRECO Programmation 


Le GRECO Programmation mène un certain 
nombre d’actions (conférences, stages...) qui 
visent à diffuser la connaissance auprès de 
l'ensemble des milieux professionnels (voir 
chapitre Actions industrielles du GRECO Pro- 
grammation). 


Quelques références 
de produits au stade 
industriel 

ou candidats 

à l’industrialisation 


e Le système MENTOR de génie logiciel en 
cours de commercialisation par la SEMA a 
bénéficié des travaux de l’équipe INRIA du 
GRECO Programmation. 

o Le langage BLAISE du terminal français 
STEP commercialisé par AMAÏA est un pro- 
duit du LRI d'Orsay. 

e Un interpréteur de LOGO en LISP a été 
développé par le LIPT (Paris 6) dans le cadre 
d’un contrat avec le CNDP. 

e Langage SCHEME d'intelligence artificielle 
développé à Paris 8 dans le cadre d’une colla- 
boration avec la société N.C.R. 

e L'interprète PROLOG/CNET implanté sur 
les matériels DPS et Multics des centres de 
calcul des Universités et de PINRIA est 
actuellement commercialisé par la société 
CRILL sous le nom de PROLOG/P. 

eLe système OASIS de manipulation de 
types abstraits développé par l'équipe du 
CNET. 

o Les traducteurs PLI/C et PASCAL/ADA de 
l’équipe GRECO Programmation INRIA Roc- 
quencourt sont au stade industriel. 
eL’éditeur multifenêtre WINNIE du LRI 
d'Orsay. 

8 PROLOG 11 du GIA de Marseille pour maté- 
riel DEC, HP, SM90, IBM PC et compatibles, 
Apple II et Macintosh, commercialisé par la 
société PROLOGIA. 

e Le langage Acteurs PLASMA et son exten- 
sion ALOG développés au LSI de Toulouse. 
e FORMES est un environnement de pro- 
grammation pour la synthèse et composition 
musicale diffusé par la société ACT informa- 
tique (LITP Paris 6 et IRCAM). 

e La société AMAIA installée à Bayonne 
commercialise la machine LISP MAIA, réali- 
sée par la CGE dans le cadre des travaux 
menés par les équipes du CNRS, de FINRIA et 
du CNET. 

e Le-LiSP de l'INRIA commercialisé par la 
société ILOG. 

6 LORE est un logiciel prototype de program- 
mation par objets développé par les Iabora- 
toires de la CGE à Marcoussis et diffusé par la 
société ISR. 

+ Le langage CAML diffusé par la société 
ILOG. 

e Le langage LPG de programmation généri- 
que. 


& ASPEGIQUE pour la manipulation de types 
abstraits, 

e Le langage REVE de déduction automati- 
que, 

e Méta-Vlisp et Méta-Objets, opérationnels 
notamment sur PC et SUN3, ont été com- 
mandés par le CNDP (Centre National de 
Documentation Pédagogique). 


& ADA est au centre de nombreux projets à 
PINRIA -(SOPHIA-ANTIPOLIS). Les logiciels 
suivants sont au stade pré-industriel ou en 
cours de réalisation : 

GRAPHADA éditeur syntaxique graphique 
pour ADA. 

ADA+ un préprocesseur orienté objets pour 
ADA. 

ADAGE un analyseur syntaxique compatible 
YACC, attribué, en ADA, générant du code 
ADA. 

PROLOG-ADA un interprète PROLOG à stra- 
tégies paramétrables écrit en ADA, interfaça- 
ble avec des packages ADA. 

e Une version portable du standard LISP in- 
dustriel COMMON-LISP sous UNIX écrite en 
Caété portée sur VAX, SUN, et SM90 (Patrick 
Greussay - Université Paris VIH). 





Réunion de l’équipe de direction élargie 


Pierre Michel Paul Patrick Patrick Emmanuel Michel Robert 
Lescanne Mouyssinat Franchi- Henry Sallé Saint-James Bidoit Cori 
Zannettacci 


L'équipe de direction 

M. Bidoit : LRI, Orsay; C. Choffrut : LITE Paris 7; A. Colmerauer : GIA Marseille, 

R. Cori : Univ. Bordeaux |, Directeur du GRECO Programmation; G. Cousineau : ENS, rue d'Ulm, 
P. Flajolet : INRIA, Rocquencourt; P. Franchi-Zannettacci : INRIA-ISI, Sophia-Antipolis. 

P. Greussay : Univ. Paris 8; P. Lescanne : CRIN Nancy; P. Salle : ENSEEIHT, Toulouse 


Les personnes suivantes sont à la disposition des chercheurs et des industriels au siège du 
GRÉCO Programmation à Bordeaux : 

Patrick Henri, Ingénieur au CNRS pour tout ce qui concerne les aspects matériels, systèmes 
et réseaux; 

Monique Claverie, pour l'organisation administrative ; 


Marie-France Dudon, pour les Actions Industrielles : secrétariat. 


Maurice Nivat au cours d'une réunion 
de l'équipe de direction élargie. 
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“LABYRINTH”, 1974, CONTRE-PLAQUÉ, MASONITE, PEINTURE À L'HUILE, 
DIAMÈTRE : 914,5 cm, HAUTEUR : 244 cm. 

COLLECTION PANZA DI BIUMO, MILAN. 





Ne ES EN @IN 


Pierre Lescanne 


Logique 
et sémantique 
de la programmation 


Dès son origine, la programmation est 
clairement apparue comme une fille de 
la logique mathématique et les grands 
progrès des logiciens des années 30 
comme Church, Curry, Güdel, Tarski et 
Turing ont immédiatement précédé la 
naissance des premiers ordinateurs et cela n'est pas fortuit. Si 
une longue période de déconnexion entre la logique et l'infor- 
matique a suivi, c'est parce que les impératifs de mise en 
œuvre occulaient la nature mathématique sous-jacente des 
processus. Ce fut la période de la bataille du “goto”. Certes, 
des pionniers, comme Landin, McCarthy, Strachey ou Scott 
proposaient tôt de fonder les langages sur la logique et, 
d'autre part, la déduction automatique fut rapidement une 
utilisatrice de logique et d'informatique, mais on n'en était pas 
encore au consensus actuel oùl'onn'imaginerait pas de définir 
un langage de programmation sans étudier les concepts logi- 
ques profondk. La sûreté est devenue un impératif et seuls des 
langages puissants et logiquement sains permettent d'at- 
teindre cet objectif. Tout cela a conduit à une interaction de 
plus en plus grande entre la com- 
munauté des logiciens et celle des 
informaticiens. Le programme de re- 
cherche concertée Programmation 


Avancée et Outils pour l'intelligence 





Aïlificielle est un acteur essentiel de ce 
renouveau. On trouve, en fait, repré- 
sentées toutes les grandes tendances 
actuelles, à l'exception de certains 
aspects ayant trait spécifiquement au 


parallélisme qui ont trouvé leur place 








au sein d'un autre programme : C8, 


e Les logiques d'ordres supérieures, 
notamment lathéorie des constructions, 
constituent, en effet, la base desträvaux 
du groupe FORMEL, qui étudie aussi ses 
implications dans la définition et l'implé- 
mentation du langage CAML. 


© La logique modale a donné lieu à un 
nouveau langage de programmation 
d'un autre genre, MOLOG, ainsi qu'au développement d'outils 


de démonstration automatique spécifiques. 


© La logique des clauses de Horn, qui sous-tend PROLOG, est 
étudiée par le groupe METHEOL. Celui-ci propose un certain 
nombre d'outils à la fois théoriques et pratiques qui permet- 
tent une meilleure compréhension et une meilleure définition 
du langage ainsi qu'une plus grande efficacité des ses mises en 


œuvre, 


© Lalogique équationnelle joue un rôle important dans les lan- 
gages de spécification modernes et asuscité des implantations 
de langages comme OBJ et des environnements de déduction 
automatique comme REVE. 


© C'est encore de logique qu'il s'agit quand l'équipe ATTRISEM 
propose des algorithmes efficaces et 
kb généraux pour les attributs séman- 


tiques. 


Toutes les équipes du pôle logique 
et sémantique ont en commun le souci 
d'allier la réflexion théorique à l'im- 
plantation de logiciels correspon- 
dants. Les présentations qui vont 
suivre montrent comment cette har- 


monie se réalise. 


= 
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METHEOL MOTS CLES 
démonstration de programmes 
intelligence artificielle 

‘ langages de cinquième génération 
logique trivaluée 

programmation par règles 

prolog 

sémantique logique 

sémantique opérationnelle 


{Bil 85] M. Billaud, “Une formalisotion des 
structures de contrôle en Prolog”, Thèse de 
3° cycle, Univ. de Bordeaux |, 1985. 


[Bil 86] M. Billaud, “Prolog control structures: 
a formalisation and its application‘, Publ, UER 
Math, Info, Université de Bordeaux. 


Cod 86a] Ch. Codognet, P. Codognet et 

G. Filé, ‘À very intelligent backtracking method 
for logic programs’, Proc of the ESOP, LNCS 
218, 1986, pp. 315-326. 


Cod 86b] Ch. Codognet, P. Codognet et 
G. Filé, “Backtracking intelligent en 
programmation logique’, Actes du Séminaire 
de Programmation en Logique de Trégastel, 


986, pp. 25-50. 


Cod 86c] Ch. Codognet, P. Codognet et 
G. Filé, “Optimization of Logic Program 
Execution Build on their static analysis’, 
RR. 86-24, Université de Bordeaux. 


Cou 87] B. Courcelle and P. Deransart, “Proof 
of partial correctness of atfribute grammars 
with application to recursive procedures and 
logic programs” Information and Control, 
1987. 


Del 86a] J.-P. Delahaye, “Outils Logiques pour 
Fntelligence Artificielle", Ed, Eyrolles, Paris, 
986. (Traduction Anglaise Kogan Page 1987. 


Del 8éb] 1.-P. Delahaye et P. Paradinas, 
“Définitions de stratégies équitables en 
programmation logique”. Actes du Séminaire 
de Programmation en Logique de Trégastel, 
1986, pp. 7-24. 












La programmation 
par règles 


Depuis quelques années, un nouveau type 
de programmation est apparu, fondé sur la 
notion de règle. Les règles en question peu- 
vent être simplement de la forme : 


si CONDITION alors CONCLUSION 
ce qu’on écrit parfois : 
CONCLUSION si CONDITION 


Il s’agit là d’un formalisme très général uti- 
lisé dans les langages de représentation de 
connaissances pour systèmes experts, dans 
la programmation logique et ses extensions 
(Prolog avec négation par exemple), et dans 
les bases de données déductives. 


Les problèmes posés par la programmation 
avec des règles sont très nombreux et liés à 
des considérations abstraites qu’il est indis- 
pensable de maîtriser faute de quoi les systè- 
mes de programmation par règles sont in- 
consistants ou inefficaces (ou les deux à la 
fois!). 

Le but de l’équipe METHEOL est de travailler 
à l’éclaircissement et au développement des 
concepts sur lesquels peut s’appuyer la pro- 
grammation logique par règle de manière à 
en tirer les conclusions pratiques (modèles 
d'implémentation, méthodologies). Ces 
concepts sont à la fois théoriques (études des 
liens formels entre de tels modèles de pro- 
grammation et la logique mathématique) et 
d’application concrète (efficacité des inter- 
préteurs de règles, compilation des program- 
mes à base de règles, méthodologie de la pro- 
grammation avec des règles). 


Sémantique 
de la programmation 
par règles 


L'intérêt de la programmation par règles 
réside dans la possibilité d'interpréter les 
unités de base d’un programme (les règles) 
comme ayant un sens intuitif logique. Les 
fondements de la programmation par règles 
doivent donc se trouver dans la logique et 
plus particulièrement dans la logique mathé- 
matique telle qu’elle a été développée depuis 
le début du siècle. Les concepts de base 
seront donc ceux de modèles et de systèmes 
formels de démonstration. 


Les nombreux travaux faits entre 1965 et 
1975, en démonstration automatique autour 
de la résolution de Robinson, fournissent un 
point de départ qui, exploité dans les travaux 
de Hill, Kowalski, Van Emden et Apt (entre 
1974 et 1982), sont maintenant universelle- 
ment reconnus comme fournissant les bases 
de toute réflexion théorique sur la program- 
mation par règles. 


Outuls ét Méthodes Théoriques 
pour la Programmation en Logique 






Mais ces travaux laissent en suspens d’assez 
nombreux points, notamment ceux qui con- 
cernent la négation. Les travaux des cher- 
cheurs du groupe METHEOL ont sensible- 
ment fait avancer la vision sémantique qu’on 
peut avoir de la programmation logique avec 
négation. À titre d'exemple, nous citerons 
les deux contributions suivantes : 


e le modèle de Ferrand et Deransart ([DeF 
871) qui s’appuie sur la notion d’univers de 
Herbrand avec variables et d’arbre de preu- 
ves. Il permet d’avoir une vision unifiée des 
différents niveaux de sémantique qu’il est 
possible d’associer à un programme Prolog 
avec négation (sémantique constructive, 
sémantique logique, sémantique opération- 
nelle non déterministe, sémantique opéra- 
tionnelle déterministe). Ce modèle sert 
aujourd’hui de base à la définition d’une spé- 
cification formelle de Prolog pour les comi- 
tés de normalisation de Prolog : BSI et 
AFNOR (voir [DeR 87]). 


e le modèle de la logique trivaluée ([Del 87a] 
[Del 87b]) fondé sur un nouveau type de 
sémantique logique (dit “à la Kripke”). Il 
donne une vue générale très simple de la 
programmation avec règles et négation per- 
mettant de retrouver pratiquement toutes 
les bonnes propriétés de la programmation 
avec règles sans négation (existence de plus 
petit modèle, calculabilité en temps raison- 
nable des plus petits modèles). 


Analyse du contrôle 
en progroammetion 
par règles 


La programmation par règles, dont l’idée de 
départ est d’être la plus déclarative possible, 
rencontre bien sûr des difficultés dans le 
contrôle du déroulement des programmes. 
Celles-ci sont traitées en Prolog par des 
moyens “très peu sémantiques” : fixation 
une fois pour toutes d’une stratégie d’exploi- 
tation des règles (dont le programmeur doit 
tenir compte pour écrire ses programmes) et 
utilisation d’opérateurs n’ayant un sens que 
purement opérationnel (comme le CUT de 
Prolog). 


Il s’agit d’un des thèmes de travail des cher- 
cheurs du groupe METHEOL. Sur ce projet, 
les travaux de M. Billaud ([Büll 66]) ont 
apporté un éclaircissement essentiel. Les 
méthodes qu'il propose permettent de com- 
parer la puissance des opérateurs de contrôle 
et de montrer que l’opérateur si-alors-sinon 
(sémantiquement assez propre) peut être 
substitué dans presque tous les cas au CUT 
(dont Putilisation détruit le sens déclaratif 
des programmes logiques). 


L’implémentation d’un Prolog fondé sur ce 
modèle a été réalisée. 


l 
| 








Responsable scientifique 
Jean-Paul Delahaye 


Étude statique 
et dynamique des 
programmes logiques 


L'analyse des programmes logiques (et sur- 
tout des programmes Prolog) est l’un des 
problèmes majeurs qui se posent aujour- 
d’hui à propos de Prolog. 

Elle doit permettre une meilleure maîtrise 
de la programmation elle-même : problème 
de méthodologie de la programmation, cal- 
cul des modes, démonstration de correction, 
de complétude et de terminaison des pro- 
grammes (travaux de P. Deransard, P. De- 
vienne, M. Dauchet, B. Courcelle). 


Cette analyse constitue un moyen essentiel 
pour l’amélioration de la compilation et de 
Pexécution des programmes logiques. Les 
travaux réalisés par Ph, et Ch, Codognet (en 
collaboration avec G. Filé de l’Université de 
Padou) et par M. Corsini sont sur ce point 
très importants, L’implémentation de leurs 
méthodes de “backtracking intelligent” a 
permis de montrer qu’à l’exécution, certains 
programmes écrits “naïvement” (c’est-à-dire 
d’une manière déclarative simple, sans utili- 
sation d’artifices de contrôle extra-logiques) 
sont aussi efficaces que ces mêmes program- 
mes additionnés des directives de contrôles 
adéquates. Ces résultats présentent un grand 
intérêt car ils montrent que le paradigme 
d’une programmation par règles, laissant à 
l’interpréteur de règles ou au compilateur de 
règles la liberté du contrôle et permettant au 
“programmeur” de ne pas sortir d’une pen- 
sée logique pure, est à prendre au sérieux 
encore aujourd’hui (ce que certains problè- 
mes rencontrés avec Prolog ont parfois mis 
en doute). 


Prospectives 


L'importance de la programmation par rè- 
gles ne semble pas devoir être remise en 
cause au cours des prochaines années et bien 
au contraire, elle apparaît comme en plein 
essor, en particulier en Intelligence Artifi- 
cielle. Les travaux du groupe MÉTHEOL qui, 
à partir d’une réflexion fondamentale, ten- 
tent d’affiner les modèles de la programma- 
tion logique, d’en préciser la méthodologie 
et d'en améliorer la compilation et lexé- 
cution sont situés au cœur de cette problé- 
matique. Ces travaux, dont il faut souligner 
Pimportance de l'apport théorique, condui- 
sent en outre à de nombreux développe- 
ments, Parmi ceux en cours, on peut citer : 
un prolog à stratégies équitables (permettant 
une meilleure gestion de la négation et limi- 
tant les boucles), un prolog intégrant les 
méthodes d'analyse de programmes de M. 
Dauchet, P. Devienne et P. Lebegue, un 
générateur de systèmes experts fondé sur la 
logique trivaluée et un prolog avec backtrac- 
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king intelligent, Ces implémentations con- 
crètes d’un intérêt pratique évident mon- 
trent, s’il en était encore besoin, que la coo- 
pération théorie-réalisation est le meilleur 
moyen d'avancer efficacement. 


Bord ea} 
Lxlles 


Participants Ph. Devienne 
B. Courcelle P. Lebegue 
M. Billaud N. Caridroit 
Ph. Codognet P. Deransart 
Ch. Codognet G. Ferrand 
S. Yoccoz M. Bergère 
M, Corsini L Lardeau 
M. Dauchet G. Richard 
G, Comyn J.-M, Kerisit 
1.-P. Delahaye 1-M, Pugin 





[Del 87a] JP. Delahaye, “Sémantique logique 
et dénofationnelle des interpréteurs prolag" 
Theoretical Informatics, 1988. 


[Del 87b] J.-P. Delahaye, “Effets de l'utilisation 
du coupe-choix sur la sémantique déclarative 
de Prolog’, Séminaire de Programmation 
Logique de Trégastel, 1987. 


[Del 87e] JP. Delahaye, “Sémantique et 
complétude du chaînage avant en calcul 
propositionnel" 7° Journées Internationales 
sur les Systèmes Experts et leurs Applications, 
Avignon, 1987. 


[DeF 87] P. Deransart et G, Ferrand, 

“An Operational Formal Definition of Prolog, 
Symposium on Logic Programming, San 
Francisco, 1987. 


[DeR 87] P. Deransart et G. Richard, “Forma 
Specification of Prolog’, Séminaire de 
Programmation Logique de Trégastel, 1987. 


[Der 85] P. Deransart and J. Maluszynski, 
“Relating logic programs and aftribute 
grammars’, J, of Logic Programming, 1986, 2, 
pp. 119-155. 


[Der 87] P. Deransart et G. Ferrand, 
“Détection d'erreurs en programmation 
logique : réalisation expérimentale”, J. of Logic 
Programming, 1987. 

[Dev 86] Ph. Devienne et P. Lebegue, 
“Weighted graphs: a tool for logic 
programming", Proc of the CAAP, Nice, 

LNCS 214, 1986, pp. 100-111. 


[Ker 86] J.-M. Keresit, J. Rohmer and 
R. Lescœur, The Alexander Method New 
Generation Computing, 4, 1986, pp. 273-285. 
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EURECA MOTS CLES 


analyse d’algorithmes 
démonstration automatique 
langage de spécification 
méthodes de spécification 
OBJ (langage orienté objet) 
réécriture 

réécriture conditionnelle 
spécifications algébriques 
spécifications formelles 
spécifications par types abstraits 
types abstraits algébriques 
unification 

validation de spécifications 
rêve 





[1] F. Bellegarde, “Rewriting systems on FP 
expressions fo reduce the number of sequences 
yielded”, Science of Computer Programming, 
6:11-34, 1986. 


[2] F. Bellegarde and P. Lescanne, 
“Transformation orderings”, in 12 th Coll. on 
Trees in Algebra and Programming, TAPSOFT, 
Springer Verlag, 1987. 


[8] S. Benachi, “Algorithmes sur les ensembles 
définis par générateurs et relations”, rapport 
de DEA de l'Université de Nancy 1, 1987. 


[4] A. Ben Cherifa and P, Lescanne, “An actual 
implementation of a procedure that 
mechanically proves termination of rewriting 
systems based on inequalities between 
polynomial interpretations”, in J. Siekmann, 
editor, Proc. 8th Conference on Automated 
Deduction, Oxford, pages 42-51, Springer 
Verlag, 1986. 


5] À. Ben Cherifa and P. Lescanne, 
“Termination of rewriting systems by polynomial 
interpretations and its implementation”, Science 
of Computer Programming, 9(2}:137-160, 
October 1987. 

6] W. Bousdira and J.-L. Rémy, “Complétion 
des systèmes de réécriture conditionnelle”, in 
Actes des Journées GROPLAN 1987, à paraître 
dans la revue BIGRE+GLOBULE, Aix-en- 
Provence, 1987. 

7] W. Bousdira and J.-L. Rémy, “Hierarchical 
contectual rewriting with several levels”, 
echnical Report, Centre de Recherche en 
nformatique de Nancy, 1987. 












Dans de nombreuses applications de l’infor- 
matique, telles la sécurité d’accès dans les 
réseaux, lPaéronautique ou plus générale- 
ment le contrôle de processus complexes, le 
problème de la correction du logiciel est pri- 
mordial. Le résoudre constitue un défiscien- 
tifique et technique. Les solutions pragmati- 
ques (tests) sont inadéquates, car si elles sont 
effectuées sur le produit final ou presque 
c'est, en général, bien tard. Tout le monde 
s'accorde à penser que la solution se trouve 
dans une discipline de programmation très 
rigoureuse du cahier des charges à la mainte- 
nance. Cette discipline requiert une phase de 
spécification où le programmateur exprime 
le problème qu’il a à résoudre dans un lan- 
gage que lui ou ses collègues doivent pou- 
voir relire aisément, mais aussi que l’ordina- 
teur peut traiter. Pour cela, il utilise un for- 
malisme rigoureux et non ambigu. Par leur 
rigueur, les spécifications ressemblent aussi 
bien à des programmes qu’à des énoncés 
mathématiques. Leur but est de fournir un 
document formel qui exprime complète- 
ment le problème de l'utilisateur et qui sera 
utilisé tant dans la phase de programmation 
que Lors de la maintenance. En plus, on exige 
que ces spécifications fassent l’objet de véri- 
fications rigoureuses, similaires à des preu- 
ves mathématiques, afin d’être certain qu’el- 
les correspondent bien à ce que l’on veut. 
Ces preuves doivent pouvoir être réalisées 
par un ordinateur ou tout au moins en inter- 
action avec lui. Seul un langage formel per- 
met une telle interaction. Il est bon que les 
spécifications soient exécutables ; ainsi, l’uti- 
lisateur obtiendra dès la phase de spécifica- 
tion un prototype de son système qui per- 
mettra les premières évaluations et fera très 
tôt apparaître les vices éventuels. 


Le formalisme des types abstraits algébri- 
ques permet cette rigueur et ces vérifica- 
tions. Un type abstrait spécifie une structure 
de données abstraite, c’est-à-dire se contente 
de préciser quelles sont les données et les 
opérations agissant sur ces données. Les pro- 
priétés caractéristiques de ces opérations 
sont décrites par des axiomes qui sont des 
formules de logique égalitaire ou du premier 
ordre en général. Les spécifications sont exé- 
cutables si la logique considérée possède un 
système de déduction complet qui permet 
de calculer dans cette logique. C’est le cas en 
particulier pour la logique égalitaire. 


Dans l'optique de construire des outils pour 
la démonstration automatique de théorèmes 
qui vont servir à valider les spécifications, 
l'activité de recherche de l’équipe s’est foca- 
lisée sur quatre domaines principaux. 


LA RÉÉCRITURE ET LA DÉMONSTRATION 
AUTOMATIQUE. La technique sur laquelle 
s’appuie l’équipe est la réécriture. Outre la 
poursuite de l'étude théorique de cet outil, le 


Étude de la Réécriture. 
_et de ses Applications. 





principal apport concerne l'exploitation des 
techniques de réécriture pour la démonstra- 
tion automatique en logique du premier 
ordre. 


LA RÉÉCRITURE CONDITIONNELLE. La tech- 
nique de réécriture conditionnelle qui per- 
met de prendre en compte des équations 
soumises à des conditions connaît d’impor- 
tants développements théoriques actuelle- 
ment. Le fait marquant dans l’équipe est un 
travail de synthèse entre plusieurs appro- 
ches. 


LES LANGAGES DE SPÉCIFICATIONS BASÉS 
SUR LA RÉÉCRITURE, Un langage de spécifi- 
cation exécutable modulaire, appelé OBJ, a 
été proposé par le groupe de J. Goguen au 
SRI. Des membres de l’équipe ont participé à 
létude et à l'implantation de la version 3 du 
logiciel. Leur recherche se centre sur l’étude 
du cadre logique et des outils de validation 
nécessaires à ce type de langage. 





ANALYSE D'ALGORITHMES. La recherche 
menée par le groupe porte sur l'évaluation 
en moyenne d’algorithmes opérant notam- 
ment dans un contexte dynamique. 
L'analyse mathématique permet de trouver 
les modes de représentation les plus effica- 
ces pour les structures de données. 


Bilan des actions 
de recherche 


La recherche menée dans le groupe est pré- 
sentée selon les quatre volets déjà mention- 
nés, à savoir : la réécriture et la déduction 
automatique, la réécriture conditionnelle, 
les langages de spécifications basés sur la 
réécriture, l’analyse d’algorithmes. 


1. RÉÉCRITURE ET DÉDUCTION 
AUTOMATIQUE 

(Responsable : Pierre Lescanne; partici- 
pants : Ahlem Ben Cherifa, Françoise Belle- 
garde, Isabelle Gnaedig, Claude Kirchner, 
Hélène Kirchner, Jalel Mzali, Pierre Réty, 
Michaël Rusinowitch.) 

Rappelons que l’équipe a développé le logi- 
ciel REVE, actuellement distribué dans une 
trentaine de laboratoires dans le monde. 
REVE apporte déjà des outils originaux dans 
le domaine de la terminaison des systèmes 
de réécriture, de a réécriture équationnelle, 
de la preuve par récurrence, des méthodes 
complètes de preuves dans le cas équation- 
nel. 

Les travaux récents sur la réécriture et la 
déduction automatique ont porté dans 
quatre directions : 


e les preuves de terminaison des systèmes de 
réécriture, 


e l'unification et la disunification, 
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e la confluence, 


e les méthodes de démonstration automati- 
que fondées sur les méthodes de la réécri- 
ture. 


D'autre part, un effort en direction de la dif- 
fusion des connaissances a été fait par la dif- 
fusion des deux articles de synthèse sur le 
sujet [19,29]. 


LL LA TERMINAISON DES SYSTÈMES DE 
RÉÉCRITURE 

La terminaison des systèmes de réécriture 
est un problème essentiel. En effet, ces étu- 
des conduisent à la preuve de terminaison 
des programmes fonctionnels, problème 
important par lui-même; mais elles inter- 
viennent aussi de façon décisive dans la pro- 
cédure de complétion de Knuth et Bendix. 
Le problème est indécidable, par consé- 
quent, il ny a pas d’algorithme qui permette 
de prouver la terminaison des systèmes de 
réécriture. En revanche, des méthodes parti- 
culières ont été définies et REVE en implante 
un certain nombre. 


Pour les non-spécialistes,. la méthode de 
preuve de terminaison fondée sur des va/ua- 
tions polynémiales est la plus populaire, bien 
que n'étant pas la plus simple à utiliser. Elle 
n'avait cependant jamais regu d’implanta- 
tion convaincante, Ahlem Ben Cherifa et 
Pierre Lescanne ont proposé une méthode 
de preuve fondée sur des principes simples 
qui vient à bout de pratiquement tous les sys- 
tèmes pour lesquels nous connaissions une 
preuve par cette méthode, preuve en général 
bien fastidieuse à la main [4,51 Cette 
méthode a été implantée dans REVE. En fait, 
une version simplifiée du problème peut se 
ramener à montrer qu’un polynôme à plu- 
sieurs variables ne prend que des valeurs 
positives sur {(x4..x)) R’Îx;>1}. Des étu- 
des fondées sur la méthode de Sturm sont 
menées pour obtenir si possible un algo- 
rithme de décision [39]. Une approche fon- 
dée sur la transformation du système de ré- 
écriture par un autre système de réécriture a 
aussi été proposée par Pierre Lescanne et 
Françoise Bellegarde [2]. Les deux systèmes 
de réécriture doivent satisfaire entre eux une 
propriété de cohérence qui s’apparente à la 
confluence et se teste de manière similaire. 
Un problème important en réécriture, ces 
dernières années, a été l’extension des 
méthodes de preuve de terminaison classi- 
ques au cas de [a réécriture équationnelle. 
Isabelle Gnaedig, en collaboration avec 
Pierre Lescanne, a développé un ordre per- 
mettant de prouver la terminaison de Ja ré- 
écriture modulo un ensemble d’axiomes 
associatifs-commutatifs. Le principe de 
base, dû à D. Plaisted, est la transformation, 
par un système de réécriture annexe, du sys- 
tème dont on veut prouver la terminaison. 
Une preuve complète de la validité de cette 
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méthode a été établie dans [16]. La méthode 
des valuations polynômiales proposée ci- 
dessus [5] s'applique aussi très bien au cas 
associatif et commutatif et c’est actuelle- 
ment la seule méthode proposée dans REVE. 


12. L’'UNIFICATION ET LA DISUMIFICATION 
L’unification est au centre de la déduction 
automatique. Les travaux de Claude Kirch- 
ner ont conduit à une méthode de résolution 
d'équations modulo des axiomes qui fonc- 
tionne dans de nombreux cas [23]. Il a mis 
par ailleurs en évidence une classe de théo- 
ries dites syntaxiques pour lesquelles un 
algorithme de décision de Punification se 
déduit automatiquement de la syntaxe des 
axiomes [21]. Une spécification complète de 
la méthode en OBJ a été écrite (voir le para- 
graphe sur les réalisations en OBJ), La 
méthode générale a été également appliquée 
à la combinaison d’algorithmes d’unifica- 
tion, et a en particulier conduit à la concep- 
tion d’un nouvel algorithme d’unification 
associative-commutative [22]. Une autre 
méthode d’unification équationnelle a été 
étudiée, appelée surréduction. Elle est essen- 
tiellement fondée sur une variante de la ré- 
écriture qui utilise l'unification classique là 
où on utilisait le filtrage [37,33,36,38]. On 
réécrit Péquation à résoudre en faisant appa- 
raître un sous-terme à réécrire grâce à une 
unification. En eumulant les substitutions 
introduites de proche en proche à chaque 
étape, on construit la solution finale. 

Le problème voisin de Ja disunification a été 
abordé. I s’agit de la résolution de systèmes 
où apparaissent, outre Les égalités habituel. 
les de l'unification, des diségalités, c’est-à- 
dire des expressions de la forme s == 7. Une 
solution fondée sur un ensemble de règles 
d’inférence a été proposé [9,26]. Des algo- 
rithmes de filtrage ont été aussi étudiés. 
Par ailleurs, Claude Kirchner a organisé une 
rencontre internationale sur l’unification qui 
a eu lieu au Val-d’Ajol dans les Vosges [24]. 


13. LA CONFLUENCE 

La procédure de complétion de Knuth et 
Bendix est utilisée pour produire un système 
de réécriture confluent et noethérien per- 
mettant de décider de l'égalité dans une 
théorie équationnelle, c’est-à-dire pour pro- 
duire un algorithme capable de prouver ou 
de réfuter un théorème équationnel. 
Malheureusement, il existe de nombreux 
cas où cette procédure diverge en produisant 
une infinité de règles que l’on peut cepen- 
dant décrire finiment. Des études de l’inté- 
terminisme de la complétion vis-à-vis de 
l'ordre choisi, tantôt divergeant, tantôt pro- 
duisant un système en un temps fini, ont été 
réalisées grâce à RÉVE et développées sur des 
exemples [14, 30]. Hélène Kirchner a étudié 
comment malgré tout définir un concept de 
réécriture à l’aide d’une infinité de règles. 
Elle utilise pour cela des méfa-règles. Par ce 
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moyen, elle obtient une méthode de déci- 
sion pour la théorie équationnelle sous- 
jacente [27]. 

La complétion est aussi utilisée pour les 
preuves par récurrence dans les théories 
équationnelles [28]. 

Françoise Bellegarde a étudié comment des 
systèmes confluents et noethériens pou- 
vaient être appliqués à la transformation de 
programmes fonctionnels [1]. 

Dans un registre un peu différent, il a été 
prouvé que le problème de la confluence des 
systèmes de réécriture de termes clos, c’est- 
à-dire sans variables, est décidable [10]. 


14, LES MÉTHODES DE DÉMONSTRATION 
AUTOMATIQUE FONDÉES SUR 

LA RÉÉCRITURE, 

Par une nouvelle méthode fondée sur des 
arbres sémantiques transfinis, Michaël Rusi- 
nowitch [40] a pu prouver la complétude de 
stratégies de démonstration automatique 
connues depuis longtemps, mais dont la 
preuve de complétude résistait, faute d’ou- 
tils théoriques adéquats, Ces stratégies sont 
liées à la paramodulation qui est une règle 
d’inférence permettant de prendre en 
compte l'égalité, Michaël Rusinowitch 
montre comment les techniques de réécri- 
ture peuvent améliorer ces stratégies. Il a 
notamment, en collaboration avec Jieh 
Hsiang, professeur à l’Université de Stony 
Brook (State University of New York), mis 
au point une procédure de complétion sans 
échec [7] qui a été implantée par Jalel Mzali 
[32]. Cette procédure est sans échec, car si 
elle ne peut pas orienter une équation en 
règle de réécriture, cause habituelle de 
léchec, elle continue son exécution en utili- 
sant les équations de façon non orientée. La 
preuve de complétude montre que cette stra- 
tégie fournit une procédure de semi-déci- 
sion pour toute les théories équationnelles, 
c'est-à-dire une procédure qui prouve mais 
ne réfute pas forcément. Des règles d’infé- 
rence pour les axiomes de régularité ont 
aussi été décrites [18]. 


2. RÉÉCRITURE CONDITIONNELLE 
Responsable : Jean-Luc Rémy; participants : 
Wadoud Bousdira, Hélène Kirchner, Stefan 
UÜhrig). 

Les recherches sur les systèmes de réécriture 
conditionnelle se sont poursuivies au sein du 
projet, avec pour support le logiciel expéri- 
mental REVEUR-4. L’effort a porté principale- 
ment sur trois axes de travail : 

1. Amélioration du logiciel REVEUR-4, pour 
augmenter en particulier le nombre de fonc- 
tions qu’il est capable de prendre en compte. 
2. Extension de l’étude théorique des systè- 
mes de réécriture conditionnelle à plusieurs 
niveaux de hiérarchie. 
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Étude de la réécriture et de ses applications 


3. Réalisation d’un travail de synthèse entre 
plusieurs approches, en particulier celle des 
systèmes hiérarchiques et celle des systèmes 
réduisants. 


2.1. RÉALISATIONS LOGICIELLES 

Le logiciel REVEUR-4 permettait jusqu’à 
maintenant de tester la confluence sur les 
termes clos de systèmes hiérarchiques à 
deux niveaux, et de vérifier, en outre, une 
propriété dite de bonne couverture des pré- 
conditions des règles. L’effort de cette année 
a porté sur le problème de la complétion 
d’un système qui n’est pas confluent sur les 
termes clos. Une réalisation a été effectuée ; 
elle a permis de compléter plusieurs systè- 
mes hiérarchiques associés à des spécifica- 
tions algébriques de types abstraits. De 
l’autre côté, comme il s’agit d’un problème 
difficile, la réalisation effectuée a également 
permis de mieux comprendre dans quelles 
directions faire porter nos efforts. La nou- 
velle version du logiciel REVEUR-4 a été pré- 
sentée au cours d’un exposé aux journées 
AFCET-GROPLAN à Aix-en-Provence (Fé- 
vrier 1987} {6] et dans des sessions de 
démonstration à la conférence STACS à 
Passau (RFA) (Février 1987) [8]. 


2.2. EXTENSION DE L'ÉTUDE THÉORIQUE 
A PLUSIEURS NIVEAUX DE HIÉRARCHIE 

I est naturel de vouloir considérer un 
nombre arbitraire de niveaux de hiérarchie. 
Cela nécessite une étude très minutieuse des 
mécanismes en présence, En particulier, plu- 
sieurs propriétés entrent en ligne de compte 
et il est nécessaire de les supposer acquises 
au niveau »—1 pour être en mesure de véri- 
fier qu’elles persistent au niveau n. Égale- 
ment, il est apparu en cours d'étude qu’il 
pouvait être nécessaire de considérer, pour 
une propriété donnée, de nombreuses 
variantes de celle-ci, selon que l’on se place, 
par exemple, dans le cadre équationnel ou 
dans le cadre opérationnel (c’est-à-dire avec 
des règles de réécriture) et dans ce dernier 
cas, selon que l’on utilise les règles sans res- 
trictions ou bien avec des restrictions hiérar- 
chiques. Une comparaison approfondie de 
ces variantes a été menée. Le résultat final de 
cette étude est un théorème donnant des 
conditions suffisantes de confluence sur les 
termes clos pour un nombre arbitraire de 
niveaux de hiérarchie. Il fait Pobjet d’un 
article à paraître [7]. 


2.3 TRAVAIL DE, SYNTHÈSE. ENTRE LES APPRO- 
CHES DES SYSTÈMES HIÉRARCHIQUES ET 
DES SYSTÈMES RÉDUISANTS 

Alors que l’approche des systèmes hiérarchi- 
ques, commencée à Nancy, a constitué le 
premier effort conséquent pour entre- 
prendre l’étude des systèmes de réécriture 
conditionnelle, une deuxième approche, 


celle des systèmes réduisants, initiée par Sté- 
phane Kaplan à Orsay, s’est avérée égale- 
ment intéressante, Jusqu'au début de 1987, 
ces deux approches avaient évolué de 
manière indépendante, bien que leurs pro- 
moteurs respectifs se soient tenus mutuelle- 
ment au courant de leurs travaux. Cette 
année, un travail commun de synthèse a été 
entrepris par ces derniers. Il a par exemple 
montré que le concept de forme normale 
contextuelle, développé d’abord dans le 
cadre des systèmes hiérarchiques, s’adapte 
au cadre des systèmes réduisants. Ce con- 
cept est l’extension naturelle du concept de 
forme normale au cas conditionnel. Des 
lumières importantes ont également été 
apportées en ce qui concerne la nature des 
spécifications conditionnelles dans lesquel- 
les les préconditions sont des expressions de 
sorte booléenne. Ce problème avait pour 
Pessentiel été laissé dans l'ombre jusqu’à 
présent dans la mesure où les systèmes don- 
nés en exemple se comportaient toujours 
comme on pouvait s’y attendre. Sans entrer 
dans les détails, disons que deux propriétés 
doivent être satisfaites pour que l’on soit 
assuré d’un comportement correct : {a com- 
plétude suffisante et la consistance relativepar 
rapport aux booléens. Il se trouve que l’on 
retrouve là des propriétés classiques dans 
létude des types abstraits. Les premiers 
résultats de ce travail de synthèse ont été pré- 
sentés d’une part au colloque MCC-INRIA 
sur la résolution des équations dans des 
structures algébriques [20] et d'autre part au 
st Workshop on Conditional Term Rewrit- 
ing Systems [35]. 


3. LANGAGES DE SPÉCIFICATIONS 
BASES SUR LA RÉÉCRITURE 
(Responsables : Claude Kirchner, Hélène 
Kirchner; participants : Isabelle Gnaedig, 
Aristide Mégrelis). 

Ce projet est centré autour de la conception 
et de la réalisation d’un langage de spécifica- 
tions exécutables et de son environnement. 
Ïl comporte plusieurs aspects, théoriques et 
pratiques, qui se regroupent en deux thèmes : 


e La réalisation d’un prototype. 


e L'étude d’outils théoriques pour l’implan- 
tation : réécriture parallèle, paramétrisation, 
compilation. 


Ce projet devrait conduire ainsi à la concep- 
tion d’environnements de programmation 
permettant à lutilisateur de s'assurer de la 
correction de ses programmes. Il s'inscrit 
dans le cadre de la poursuite de {a collabora- 
tion qu’Hélène et Claude Kirchner ont enta- 
mée avec Péquipe de Joseph Goguen et José 
Meseguer lors de leur séjour au SRI en 1985-86. 
Une condition préliminaire à l'élaboration 
d’un tel projet est de partir d’un langage pos- 
sédant une sémantique et un mécanisme 
d’inférence clairs. Le langage OBJ développé 





au SRI par l’équipe de I. Goguen et J, Mese- 
guer, est un langage de spécification de haut 
niveau pour les types abstraits algébriques. 
OBJ a une sémantique algébrique basée sur 
les algèbres à sortes ordonnées, qui sont des 
algèbres dont le domaine est composé de dif- 
férentes sortes avec des inclusions possibles 
entre elles. La théorie des algèbres à sortes 
ordonnées permet le polymorphisme et la 
surcharge des opérateurs, le traitement et la 
récupération des erreurs, l'héritage de pro- 
priétés et les contraintes de sortes grâce aux- 
quelles il est possible d’exprimer certaines 
fonctions partielles comme des fonctions 
totales sur un sous-domaine défini par des 
équations. Les entités de base du langage 
sont les objets décrits par des sortes, des 
fonctions et des équations, 


Le mécanisme d’inférence d’OBJ est une 
généralisation de la réécriture équationnelle 
et conditionnelle standard qui prend en 
compte la relation d’inclusion entre les sor- 
tes. Certaines caractéristiques du langage, 
telles la modularité, le traitement et la récu- 
pération d'erreurs ou les contraintes de sor- 
tes posent des problèmes théoriques délicats 
à résoudre, 

Afin de fournir des outils de certification 
pour les programmes OBJ, et plus générale- 
ment pour des langages basés sur la logique 
équationnelle, il s’agit d’analyser le type de 
preuves qu’il est souhaitable de pouvoir faire 
de façon automatique. Par exemple, Putilisa- 
teur peut spécifier que l’importation dans 
son programme d’un objet préalablement 
défini ne modifie pas le comportement de 
cet objet. Ce problème est lié à la preuve de 
théorèmes en logique équationnelle et du 
premier ordre pour lequel Le formalisme des 
règles de réécriture s’avère puissant et bien 
adapté. Il en découle que la seconde base du 
projet est un démonstrateur de théorèmes 
en logique équationnelle et du premier ordre 
basé sur la complétion des systèmes de réé- 
criture. 


3.1. RÉALISATIONS LOGICIELLES 

e La version 3 d’OBJ. Le travail d’implanta- 
tion d’OBJ-3, commencé en 85-86 au SRI, 
s’est poursuivi cette année, notamment au 
cours de deux séjours : le premier est celui de 
Tim Winkler du SRI pendant un mois à 
Nancy, le second est celui de Claude Kirch- 
ner au SRI pendant deux semaines. Ces 
séjours ont permis d’améliorer certains 
aspects du système. 


e La complétion unificationnelle en OBJ. Une 
procédure de construction automatique 
d’algorithmes d’unification pour la classe 
des théories syntaxiques a été prouvée puis 
spécifiée en OBJ. Ce travail a permis par ail- 
leurs de tester le logiciel OBJ-3, à la fois sur le 
plan de l'efficacité et sur celui du confort 
d'utilisation et de conception des program- 
mes. 


e OBJ pour OBJ. À mi-chemin entre la réali- 
sation logicielle et l'étude théorique, un 
compte rendu d'expérience sur la spécifica- 
tion de l’interpréteur OBJ-3 dans le langage 
OBJ a été fait : il défend la thèse qu’un travail 
précis de spécification est indispensable 
avant la programmation de gros logiciels et 
analyse les avantages et les inconvénients 
d’OBJ pour spécifier de tels gros programmes. 


3,2. RÉALISATIONS THÉORIQUES 

Les réflextions théoriques sur le projet se 
sont concrétisées par des articles dans deux 
domaines : 

eÉtude de la sémantique opérationnelle 
d’OBJ. OBJ'utilise un mécanisme de déclara- 
tion de sous-sortes très puissant et permet- 
tant une grande flexibilité d’expression. Il 
permet en particulier de traiter le problème 
des erreurs de facon élégante et correcte. En 
contre-partie, les règles de déduction 
deviennent plus complexes et le remplace- 
ment d’égaux par égaux n'est plus une 
méthode d’inférence complète. L'équiva- 
lence de deux termes doit tenir compte de la 
relation de sous-type. On peut trouver dans 
[25] une étude de la déduction dans les algè- 
bres à sortes ordonnées, de son équivalence 
avec la réécriture sur des sortes ordonnées, 
ainsi que la description de l’interpréteur 
d’OBJ-3 et des choix qui y ont été faits. 


e Étude de la complétion ordo-sortée. Il 
s'avère que la complétion des systèmes de 
réécriture est un outil fondamental de vali- 
dation de programmes écrits dans un lan- 
gage basé sur la logique équationnelle. 


L'utilisateur d’OBJ est supposé écrire ses 
programmes sous forme de systèmes de réé- 
criture possédant la propriété de Church- 
Rosser. Cette hypothèse est primordiale 
pour que l'évaluation d’un calcul puisse se 
faire par réécriture et que le résultat soit uni- 
que. Si la vérification de la propriété de 
Church-Rosser est aisée pour de petits pro- 
grammes, il n’en est pas de même pour des 
types de données complexes et comportant 
des mélanges de règles et d'équations dans 
lesquels l'intuition de programmeur est 
alors mise en défaut. Une étude systémati- 
que de la complétion de systèmes de réécri- 
ture équationnelle dans les algèbres à sortes 
ordonnées a été réalisée dans [15]. Les pro- 
blèmes spécifiques à la logique des algèbres 
à sortes ordonnées sont clairement mis en 
lumière. 


4. ANALYSE D’ALGORITHMES 

L'étude des structures de données dynami- 
ques dans le modèle de D.E. Knuth a été 
poursuivie et la réalisation pratique du sys- 
tème DECIDE est en cours [3]. Ce sera un 
outil d'analyse automatique d’ensembles 
définis par générateurs et relations et cela 
aura des applications concrètes en parallé- 


lisme, puisque d’après les travaux de Flé, 
Cori, Minoura et Roucairol on sait que le 
modèle sous-jacent est le monoïde partielle- 
ment commutatif, Des résultats nouveaux 
ont aussi été obtenus par notre groupe dans 
l'étude des structures dynamiques. A l’aide 
de techniques combinatoires, nous avions 
obtenu les coûts moyens de séquences 
d'opérations (adjonctions, suppressions, 
interrogations positives ou négatives) effec- 
tuées sur des fichiers représentés sous forme 
de listes linéaires ou de files de priorité, mais 
des genres plus compliqués comme les dic- 
tionnaires ou les tables des symboles ainsi 
que le cas où l'univers des clés est borné, 
demeuraient hors d’atteinte avec cette 
approche. Nous avons donc développé des 
outils algébriques permettant précisément 
l’analyse de ces cas, ainsi que létude des pro- 
fils limites, Ces résultats constituent la 
réponse à des questions posées par D.E. 
Knuth [12, 13, 34, 11]. 


Orientation future 
des recherches 


Dans la suite logique des travaux théoriques 
menés dans l'équipe, nous nous orientons 
dès maintenant vers la construction d’envi- 
ronnements intégrés pour la preuve et la spé- 
cification de logiciels, au sein de deux projets 
nouveaux. L'aspect preuve correspond au 
projet RÉVEAL, Paspect environnement de 
programmation sûre correspond au projet 
TIPE, 


1. PROJET RÉVEAL 

REVEAL est un projet international qui fait 
intervenir des chercheurs de l'Université de 
Stony Brook, Jich Hsiang et Leo Bachmair, 
du LRI à Orsay et de l’équipe EURECA. Son 
butest d'étudier des systèmes de démonstra- 
tion automatique essentiellement fondés 
sur des règles d’inférence. L'accent est mis 
sur les règles qui réduisent l’espace de 
recherche, par exemple la simplification par 
réécriture. Un autre point à examiner est la 
notion de contrôle qu’il faut ajouter aux 
règles d’inférence pour avoir prise sur les 
stratégies de preuve et sur leur efficacité lors 
de l'exécution. Notre programme immédiat 
consiste à préciser l'architecture du logiciel, 
les caractéristiques du langage de com- 
mande et les algorithmes de preuves dans 
différentes logiques. 


2. PROJET TIPE 

Le nom TIPE correspond aux quatre mots 
anglais, Types, Inheritance, Polymorphism et 
ÆEqualities, Le but du projet est d’étudier et 
de réaliser un environnement sir de pro- 
grammation intégrant un langage de spécifi- 
cation puissant et exécutable à son environ- 
nement de preuve. Son objectif est de per- 
mettre le développement d'applications cri- 
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[lé] 1. Gnaedig and P, Lescanne, “Proving 
termination of associative rewriting systems 
by rewriting” in J. Siekmann, editor, Proc. 
8th Conference on Automated Deduction, 
Oxford, Springer Verlag, Lecture Notes in 
Computer Science, Oxford (England), 1986. 


[17] J. Hsiang and M, Rusinowitch, "On word 
problems in equational theories’, in Int Coll. on 
Automata Languages ond Programming, 1987. 


8] 1. Hsiang, M. Rusinowitch, and K. Sakaï, 
“Complete inference rules for the cancellation 
laws” in Int. Joint Conf. on Artificial Intelligence, 
1987. 


19] J.-P. Jouannaud and P. Lescanne, 
“La réécriture’, Techniques et Sciences 
Informatiques, 5(6), 1987. 


20] S. Kaplan and J.-L. Remy, “Completion 
algorithms for conditional rewriting systems’, 
in Proc. Colloquium on Resolution of Equations 
in Algebraic Structures, MCC, 3500 West 
Balconies Center Drive, Austin, Texas 78759- 
6509, May 4-6 1987. 


[21 €. Kirchner, “Computing unification 
algorithms", in Proceeding of the first 
symposium on Logic in Computer Science, 


Boston (USA), pages 206-216, 1986. 


[22] C. Kirchner, “From Unification in 
Combination of Equational t À New AC- 
Unification algorithm", Technical Report 
87-R-132, Centre de Recherche en 
Informatique de Nancy, 1987. To appear 
in the proc. of the CREAS. 





Étude de la réécriture et de ses applications 


tiques telles qu’elles apparaissent en aéro- 
nautique ou dans les industries à haut risque 
(centrales nucléaires...). Le projet est en 
cours de définition avec des partenaires 
industriels belges et anglais et des universi- 
taires français et allemands. II fera l’objet 
d’une soumission au programme européen 
ESPRIT-2. 


3. ASPECTS FONDAMENTAUX 

Les travaux théoriques liés à nos quatre 
domaines de recherche actuels s’intègrent à 
la recherche fondamentale qui sous-tend ces 
deux projets. Chaque pôle poursuit des 
objectifs très précis. 


3.1. RÉÉCRITURE ET DÉDUCTION 
AUTOMATIQUE 

Sur la terminaison, l’étude des systèmes de 
réécriture associative et commutative néces- 
site d’être poursuivie pour être mieux com- 
prise. Sur la méthode des valuations polynô- 
miales, nous comptons créer des systèmes 
qui aident l'utilisateur à trouver les valua- 
tions, l’un des points délicats de la méthode, 
D'autre part, puisque la méthode par trans- 
formation est fondée sur une propriété 
proche de la confluence, nous voulons déve- 
lopper une procédure qui fonctionnerait 
comme une complétion et qui offrirait auto- 
matiquement les différents paramètres de la 
preuve de terminaison. 

Dans le domaine prometteur de l'étude de la 
désunification, domaine dans lequel seuls 
les premiers pas ont été faits, nos recherches 
porteront sur ses liens avec la surréduction. 


3.2. LA RÉÉCRITURE CONDITIONNELLE 


Les perspectives concernant la réécriture 
conditionnelle ont été dégagées pour l’es- 
sentiel à l’intérieur de la présentation précé- 
dente. Nous comptons poursuivre la re- 
cherche théorique sur les systèmes hiérar- 
chiques, développer une implantation sur 
des bases nouvelles, en prenant en particu- 
lier en compte la description des algorithmes 
par des règles d’inférence, et progresser dans 
la synthèse entre les différentes approches, 
Ces différents points s’intègrent dans le tra- 
vail de thèse de doctorat de Wadoud Bous- 
dira, chercheuse associée au projet. 


3.3. LANGAGES DE SPÉCIFICATIONS BASÉS 
SUR LA RÉÉCRITURE 

L'expérience acquise grâce à l'étude appro- 
fondie du fangage OBJ et de ses mécanismes 
permet de mieux appréhender les problèmes 
qui sont au centre du projet TIPE, Conti- 
nuant dans cette voie, nos projets sont 
létude, la généralisation et Pimplantation 
d'outils permettant de valider des program- 
mes, c’est-à-dire de montrer Punicité de 
leurs résultats et leur terminaison. Ces outils 


tiendront compte de lastructuration des pro- 
grammes permise par les mécanismes d’en- 
richissement et de paramétrisation. 


3,4. ANALYSE D’ALGORITHME 

Les recherches vont s’orienter vers l’analyse : 
e d’algorithmes liés à la réécriture (filtrage, 
unification, surréduction), par des techni- 
ques de fonctions analytiques (Méthode du 
col, transformée de Mellin, etc.), 


e de systèmes de réécriture (des résultats 
partiels ont été obtenus par P. Lescanne, C. 
Choppy, $. Kaplan, J.L. Remy et M. Soria) et 
vers l'introduction d’outils probabilistes 
sophistiqués pour affiner l'étude des structu- 
res de données dynamiques dans le modèle 
de Knuth. D’autre part, H. Amet a entrepris 
un travail portant sur la conception et 
Panalyse de processus décisionnels pour les 
déplacements dans R? et R. 


| 
| 
| 











{231 C. Kirchner, “Méthodes ef outils de 
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d'unification dans les théories équationnelles”, 
Thèse d'État de l'Université de Nancy !, 1985. 


24] C, Kirchner, editor, “Proceedings on a 
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“Operational semantics of OBJ3’, Technical 
Report 87-R-87, Centre de Recherche en 
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disequations’, in Proc. IEEE 2nd Symp. an Logic 
in Computer Science, 1987. 
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of rewrite rules, application to the divergence 
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Rewriting Techniques and Applications, pages 
180-191, Springer Verlag, 1987. 
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Implementation, Technical Report 682, INRIA, 
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Report CRIN 87-R-051, Centre de Recherche 
en Informatique de Nancy, 1987. Invited 
Conference at 1M Symposium on Current 
Trends in Computer Algebra. 
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Bendix procedure and termination orderings’, 
Bull. EATCS, 30:80-83, October 1986. 


[31] P. Marchand and R. Schott, “Résolution par 
algorithmes de problèmes dans les groupes 
libres’, Technical Report 86-R-066, CRIN, 1986. 


32] J. Mzali, "Méthodes de filtrage 
équationnel et de preuve automatique de 
théorèmes’, PhD thesis, Université de Nancy |, 
September 1986. 


33] W. Nutt, P. Rety, and G. Smolka, “Basic 
Norrowing Revisited”, Technical Report 
SR-87-07, Universität Kaiserslautern, West 
Germany, July 1987. 


34] B, Randrianarimanana, “Analyses des 
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Université de Nancy |, 1986. 
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de l'Université de Nancy 1, March 1988. 


37] P. Réty, “lmproving basic narrowing 
techniques and commutation properties in 
2nd International Conference on Rewriting 
Techniques and Application, 1987. 
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ATTRISEM MOTS CLES 

Ada (langage de programmation) 
attributs sémantiques 
environnements de programmation 
grammaires attribuées 
grammaires d'arbres 
programmation logique 

prolog 

sémantique dénotationnelle 
sémantique des langages 
spécifications formelles 

types abstraits algébriques 





[Zar 86] A. Zarli, “Édition structurée : 
application à un éditeur de texte guidé par 
la syntaxe pour le langage ADA°, journées 
ADA/AFCET ENST, Paris, 1986. 


[AF 87] 1. Attali, P. Franchi-Zannettaci, 
“inference system environment for ADA', conf. 
ADA-EUROPE, Stockholm, 1987. 


[A 88] 1. Attali, “Compiling out unification 
in TYPOL*, conf, INFORMATIKA, Nice, 1988. 


[Lev 88] D. Levi, “Problèmes de réutilisation liés 
av typage, application à une extension du 
langage ADA’, thèse de doctorat, Université 
de Nice, 1988. 


[DJL 88] P. Deransart, M. Jourdan, B, Lorho, 
“A survey on Attribute Grammars', INRIA RR 417, 
485, 570 mis à jour et à paraître chez Springer 
Verlag. 


[CD 87] B. Courcelle, P. Deransart, “Proof of 
Partial Correciness of Aftribute Grammars with 
Application to Recursive Procedure and Logic 
Programming’, Université de Bordeaux, 
RR18702, à paraître dans Information and 
Computation. 


(DM 85] P. Deransart, J. Maluszynski, “Relating 


Logic Programs and Atribute Grammars’, 

d. of Logic Programming 1985, 2 pp 119-155. 
{Bar 87] K. Barbar, “Atributed Context-Free 
Tree Grammars’, Université de Bordeaux |, 
RR 8716, avril 1987. 

[Fit 87] G. Filé, “Classical and Incremental 
Evaluaïors for Atribute Grammars”, TCS 53,1, 
1987, pp 25-65. 





Le rapport ALGOL60 révisé en 1962 définis- 
saît informellement, c’est-à-dire en langage 
courant, la Sémantique du langage, c’est-à- 
dire la fonction calculée par un programme 
supposé syntaxiquement correct. Comme 
D. Knuth l’a bien montré, cette définition 
laissait de nombreuses incertitudes et ambi- 
guïtés dont la résolution revenait de facto à la 
personne chargée d'écrire le compilateur ou 
Pinterprète du langage. Le langage y perd 
ainsi son caractère d'indépendance de la 
machine qui l'implante. Cette indépendance 
devait faire du langage ALGOL, un langage 
de référence pour la définition d’algorith- 
mes, elle était donc essentielle. 

Le nécessité de définir formellement la 
sémantique des langages de programmation 
s’est donc imposée très tôt. “Formellement” 
veut dire par exemple au moyen d’un 
ensemble des déquations associées aux 
règles de syntaxe qui spécifie de manière 
unique la fonction calculée par le pro- 
gramme, et de préférence de façon opéra- 
toire, calculable par ordinateur. Une telle 
définition débouche ainsi sur la réalisation 
d’un méta-interprète, prenant en entrée la 
définition du langage et un programme, et 
fournissant le résultat. 


Comme B. Lorho l’a clairement exposé dans 
sa thèse, les définitions formelles des langa- 
ges de programmation concernent : 

1. Pécrivain du compilateur ou de l’inter- 
prète : la définition formelle du langage lui 
sert alors de référence, de spécification, 

2. le programmeur qui pourra l'utiliser pour 
vérifier la validité de son programme, ou en 
tout cas pour le mettre au point plus rapide- 
ment que par une suite d'essais et de correc- 
tions des erreurs, 

3. le théoricien qui cherche à comparer diffé- 
rents langages du point de vue de leur effica- 
cité, de leur facilité d'utilisation ou à définir 
des méthodologies de programmation. 
Différents formalismes ont été proposés. 
Nous n’en citerons que deux. 

La “sémantique dénotationnelle” est un for- 
malisme proche du lambda-calcul qui fait 
intervenir des constructions de domaines 
complexes. Cette technique a été utilisée 
pour mettre au point et définir le langage 
ADA. 


La seconde est la méthode des “attributs 
sémantiques” qui est l’objet des travaux du 
groupe ATTRISEM. Elle a été proposée par 
D. Kauth dans un article publié en 1968. Elle 
est plus directement apte à l'implantation car 
ses règles sémantiques sont des affectations 
d’un langage à affectation unique (c’est-à- 
dire où chaque variable ne reçoit qu’une 
valeur au cours de l’éxécution d’un pro- 
gramme), 

Cette méthode est déclarative en ce sens 
qu’elle définit des objets sans donner exacte- 
ment la méthode de calcul. (L'existence d’un 


Théorie et utilisation 
des Srammaires attribuées 





algorithme est assurée par un test, dit de non- 
circularité qui doit être fait après l’écriture 
des règles sémantiques). 

De nombreuses implantations ont été réali- 
sées dans le monde, toutes orientées vers 
Putilisation des grammaires attribuées pour 
la compilation et linterprétation des langa- 
ges de programmation. Ces implantations 
définissent des stratégies d'évaluation et 
cherchent les meilleurs compromis possi- 
bles entre des impératifs contradictoires : 
temps de calcul, espace-mémoire utilisé, 
types de grammaires attribuées acceptables 
(on ne connaît pas d’algorithme efficace qui 
accepte toutes les grammaires attribuées 
non circulaires). 


Les grammaires attribuées ont également 
fait l’objet de recherches théoriques appro- 
fondies : complexité des algorithmes d’éva- 
luation, type de relation de traduction défi- 
nie, comparaisons avec les transductions 
d'arbres, etc. 


Ï faut enfin mentionner la parenté avec d’au- 
tres formalismes tels que PROLOG, qui fait 
elle aussi le sujet de recherches prometteu- 
ses. 


Dès la création du GRÉCO PROGRAMMA- 
TION, le groupe ATTRISEM s’est constitué 
pour étudier les différents aspects théori- 
ques et pratiques des grammaires attribuées 
et a retenu les thèmes majeurs suivants : 


1. Algorithmes d'évaluation et implantation 
des grammaires attribuées : étude bibliogra- 
phique systématique [DJL 881, système 
ENC-2 [Fil 87, Par 87, JP 88] d’aide à lacompi- 
lation. Des extensions sont prévues avec 
évaluation incrémentale des attributs. 


2. Applications des grammaires attribuées : 
environnement de programmation et édi- 
teurs graphiques [AF 87, Zar 86, Lev 88], 
compilation de TYPOL, langage de spécifica- 
tions mis au point dans le projet INRIA- 
CROAP [Ait 88]. 


3. Relations entre les grammaires attribuées 
et d’autres formalismes tels que la program- 
mation en logique [DM 85, CD 87] ou les 
grammaires d'arbres [Bar 87]. Ces travaux 
ont d’abord un caractère théorique mais 
conduisent à des applications dans le 
domaine des spécifications formelles et de 
leur exécution [Att 88]. 


Logiciels “industriels” 
réalisés ou en cours 
de réalisation 

ENC-2 : spécification et évaluation de gram- 
maires attribuées. 

GRAPHADA : un éditeur syntaxique graphi- 
que pour ADA. 


ADA : un préprocesseur orienté objets pour 
ADA. 








Responsable scientifique 
P. Deransart 


ADAGE : un analyseur syntaxique compa- 
tible YACC, attribué, en ADA, générant du 
code ADA. 

PROLOG-ADA : un interprète PROLOG à 
stratégies paramétrables écrit en ADA, inter- 
façable avec des packages ADA. 


Contacts Extérieurs 


Universités de Cornell, Brandeis, Philadel- 
phie (U.S.A.), Karlsruhe, Dortmund, Saar- 
brücken (R.F.A.), Rostock, Berlin-Est (RDA), 
Moscou, Tallin (URSS), Linkôpirg, Gôte- 
borg (Suède), Helsinki (Finlande), Tokyo 
(Japon), Rio de Janeiro-Federale, Recife 
(Brésil), Braga, Lisbonne (Portugal), Impe- 
rial College (Londres), Padoue (Italie). 


Contacts Industriels 


Xerox, CR2A, Alsys, Ilog, Paris, IBM La 
Gaude, Thomson SINTRA Cagnes-sur-Mer, 
CISI Sophia Antipolis, Bull, ICL (UK). 


Projet ESPRIT n° 956 
“COCOS” 


Le projet COCOS (Components for Future 
Computing Systems) étudie une architec- 
ture ouverte pour une station de travail à 
usage bureautique, ainsi que certains com- 
posants matériels et logiciels s’intégrant à 
cette architecture. Les principaux thèmes de 
recherche dans COCOS sont les suivants : 
s implantation du langage de programma- 
tion logique parallèle PARLOG sur une base 
matérielle associant uSyC (microprogram- 
mable symbolic coprocessor) à un CPU clas- 
sique (68020 ou ARM, Acorn RISC Ma- 
chine); le compilateur de PARLOG en code 
intermédiaire SPM est réalisé à l’aide du sys- 
tème FNC-2; 

e développement de nouveaux concepts de 
programmation, en particulier la program- 
mation orientée objet, sur PARLOG; 

e développement d’une architecture, d’ou- 
tils génériques et d’outils spécialisés pour 
l'interface homme-machine ; 

© développement et implantation du langage 
orienté objet fortement typé Le-Tool, 


La contribution de l’Équipe “Langages et 
Traducteurs” de l'INRIA au projet COCOS 
porte sur les deux premiers points. Publica- 
tion : The FNC2 System : Advances in Attri- 
bute Grammars Technology. 


Organismes 

INRA. Rocquencouri 

Domaine de Voluceau Rocquencourt 
78150 Le Chesnay 

Æ (n3963551 

INRLA. Sophia-Antipolis 

Université d'Orléans 

Université de Strasbourg 





[IP 88] M. Jourdan, D. Parigot, ‘The FNC-2 
System, User's Guide and Reference Manual”, 
INRIA, février 1988. 


[Par 87] D. Parigot, "Mise en œuvre des 
Grammaires Atribuées : Transformation, 
Évaluation Inerémentale, Optimisations" thèse 
de 3° cycle, Université de Paris-Sud, Orsay, 
juin 1987. 


Participants 
GROUPE ATTRISEM 

P. Deransart 

M. Jourdan 

D. Parigot 

B. Lorho, 

C. Julié 

P, Franchi-Zannettacci 
À. Zarli 

€. Kleinhans 


M. Fornarino 
8. Chabrier 
4-P. Forestier 
4.-P. Giacometti 
L Attali 

D. Lévi 

K. Barbar 

G. Filé 

JM. Schramm 
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MODAL MOTS CLES 
compréhension du langage naturel 
démonstration automatique 
environnements de programmation 
formulation du raisonnement 
intelligence artificielle 

logique des situations 

logique modale 

logique temporelle et parallélisme 
machine abstraite/virtuelle 
MOLOG (langage de programmation logique) 
stratégie de preuve 


R'étpihée in el mueles 


Y. Aufray, ‘Linear strategy for modal 
resolution”, à paraître Information Proc. 
Letters. 


Y. Aufroy, P. Enjalbert “Modal Theorem 
proving: an equatiomal approach” Journées 
Européennes sur les méthodes logiques en LA. 
1988, Roskoff. 


Y. Aufray, P. Enjalbert, J.-J. Hébrard, 
“Strategies for modal resolution: results and 
problems, rapport LI.U.C. 87-2, université 
de Caen, septembre 1987. 


R. Arthaud, P. Bieber, L. Farifias Del Cerro, 
1. Henry, À. Herzig, “Automated modal 
reasoning, Proceedings of the Int. Conf. on 
Information Processing and Management 

of Uncertainly in knowledge Based Systems’, 
Paris, Juillet 1986. 


R. Arthaud, P. Bieber, L. Farifias Del Cerro, 
L. Henry, À. Herzig, MOLOG : “Manuel 
d'utilisation", rapport LS, février 1986. 


E. Audureau, P. Enjalbert, L. Farifñas Del 
Cerro, “Théorie de la programmation et 
logique temporelle. 1° partie : Méthodes de 
preuve T.S1, 6, 6, 1987, 2 partie : Validation 
d'algoritimes parallèles”, TSI, à paraître, 
1988. 


E. Audureau, P. Enjalbert, L. Fariñas Del 
Cerro, “Logique Temporelle : Sémantique et 
validation de programmes parallèles’, ouvrage 
à paraître chez Masson, 1988. 


S. Badaloni, Ci. Sayettai, “L'Aspect Temporel 
en Intelligence Artificielle”, Intelligence 
Artificielle et CAO en BTP, Ed. Hermès 1988. 





en logique Modale 


Suite au premier travail sur la logique des 
situations de McCarthy et Hayes, un grand 
nombre de recherches, utilisant la logique 
modale, ont été développées en Intelligence 
Artificielle dans les domaines suivants : 
Compréhension du langage naturel, Forma- 
lisation du raisonnement (raisonnement sur 
des données incomplètes ou incertaines, rai- 
sonnement temporel, raisonnement sur la 
connaissance), et dans une autre “tradition”, 
la Logique des programmes. 


L'utilisation de la logique modale en infor- 
matique pose le problème de lautomatisa- 
tion de la déduction dans ces formalismes. 
Plusieurs méthodes existent : raduction en 
logique du premier ordre classique, déduc- 
tion naturelle et résolution. 


C’est ce dernier type de méthode que notre 
projet étudie tout particulièrement. 

Cette méthode consiste à étendre la résolu- 
tion classique à la logique modale. L'intérêt 
fondamental réside dans la possibilité de 
définir des stratégies de preuve, un point 
essentiel en démonstration automatique. 
Un développement important de notre ap- 
proche a été de définir une notion de “clause 
modale de Horn”, par analogie avec les clau- 
ses du même nom en logique classique sur 
lesquelles, on le sait, est construit le langage 
Prolog. Un langage de programmation “en 
logique modale”, MOLOG, en est issu. 


Les objectifs du projet sont : 


e Développer les bases logiques de la mé- 
thode de résolution. 


e Développer MOLOG comme langage de 
programmation : implémentation, sémanti- 
que... 

© Étudier - en s'appuyant en particulier sur 
ce langage - les applications de la logique 
modale. 


Principaux résultats 
obtenus en 86 et 87 


Les travaux se sont poursuivis dans les trois 
directions suivantes : 


1. ÉTABLISSEMENT DES BASES LOGI- 
QUES DE LA RÉSOLUTION 

© RÉSOLUTION POUR LA LOGIQUE PROPOSI- 
TIONNELLE : 

En utilisant une technique basée dans la mé- 
thode de Skolem, nous avons pu définir des 
systèmes modaux (propositionnels) pour 
lesquels, d’une part, on peut donner des 
règles de résolution relativement simples et, 
d’autre part, simplifier les preuves de com- 
plétude des règles. 


e STRATÉGIES DE RÉSOLUTION : 

Un ensemble de stratégies classiques (H- 
néaire, négative, input), permettant des 
gains en efficacité, a été obtenu dans le cadre 


Un langase de programmation 





de la logique modale “classique” ou de ces 
extensions. 


e RÉSOLUTION POUR LE 1° ORDRE : 

a) Une propriété de Herbrand pour le sys- 
tème modal Q (le plus simple des systèmes 
modaux) a été établie, ce qui permet 
d'étendre la résolution au premier ordre. 
Cette méthode a été développée dans la 
thèse d’Université que Marta Cialdea a sou- 
tenue à l’Université P.-Sabatier (Toulouse). 


Cette méthode a été implémentée sous 
forme d’un démonstrateur utilisant la 
méthode du graphe de Kowalski. La défini- 
tion et la mise en place de stratégies sont en 
COUrS, 


b) Comme pour le calcul propositionnel, 
nous avons étendu aussi les techniques de 
Skolem pour la logique modale de premier 
ordre, et à nouveau, certains problèmes diffi- 
ciles en déduction automatique, cette fois-ci 
iés à la quantification, se simplifient. Nous 
avons appliqué cette technique à plusieurs 
systèmes modaux et les premiers résultats 
sont encourageants puisque nous traduisons 
les problèmes de déduction automatique en 
ogique modale par des problèmes de déduc- 
tion dans des théories équationnelles. 


2. AUTOUR DE MOLOG 

© UNE MACHINE ABSTRAITE POUR MOLOG. 

Nous avons défini une méthode pour compi- 
er des clauses MOLOG. Pour cela, un 
ensemble de primitives de programmation a 
été défini, qui étend celles de la “Machine de 
Warren”. La méthode de traduction présen- 
tée produit, à partir d’une clause MOLOG, un 
programme écrit à l’aide de ces primitives. 
Le but de ce travail est d’obtenir des implé- 
mentations efficaces pour les logiques 
modales, 

L’implémentation - actuellement en lisp - 
commence à être refaite en C pour des rai- 
sons d'efficacité évidentes. 

© SÉMANTIQUE DÉCLARATIVE POUR MOLOG. 
Une sémantique déclarative pour certains 
systèmes de logique modale a été définie. En 
faisant correspondre à chaque clause modale 
de Horn une transformation continue 
comme dans le cas de clauses de Horn classi- 
ques, on peut associer à chaque programme 
un modèle minimal. On obtient une mé- 
thode pour prouver la complétude des clau- 
ses de Horn modales de plusieurs systèmes, 
Q, T, Sd, et une compréhension informati- 
que des clauses modales de Horn. 





3. APPLICATIONS 

e RAISONNEMENT HYPOTHÉTIQUE 

Nous avons élaboré un système de logique 
modale permettant de représenter certains 
aspects liés à la mise à jour de connaissances 
dans une base de données déductive. Pour 
cela, nous traduisons la mise à jour par Pin- 
troduction d’une nouvelle hypothèse; faire 
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une requête à la base de données après avoir 
effectué une mise à jour revient à réaliser un 
raisonnement hypothétique. En d’autres ter- 
mes, la base de données n’est pas modifiée 
réellement par la mise à jour, ce qui nous 
permet de raisonner sur les mises à jour 
elles-mêmes. 


© EXPRESSIVITÉ EN LOGIQUE MODALE 
Dans le cadre d’une étude entreprise sur le 
pouvoir expressif de la logique modale, il a 
été montré que pour chaque grammaire for- 
melle G, il peut être défini une logique 
modale propositionnelle LG vérifiant la pro- 
priété suivante : 

si un mot m est engendré par la grammaire 
G, alors il existe une forme F,, associée à m 
telle que F,, est un théorème de LG. 

Une conséquence immédiate de ce travail 
est de disposer d’une méthode simple pour 
construire des logiques modales proposi- 
tionnelles indécidables. Le but de cette 
étude est d'étendre les grammaires logiques 
afin de traiter dans un même cadre formel 
des aspects syntaxiques et sémantiques liés à 
la compréhension du langage naturel. 


e LOGIQUE TEMPORELLE ET VALIDATION DE 
PROGRAMMES PARALLÈLES 

Enfin, nous avons achevé un travail de syn- 
thèse sur les applications de la logique tem- 
porelle (une des applications-variantes de la 
logique modale) à fa validation de program- 
mes parallèles, De ce travail résultent deux 
ses) parus dans T.S.L. et un livre à paraître 
en ï 


o ASPECT TEMPOREL EN INTELLIGENCE 
ARTIFICIELLE 

Afin de dégager une synthèse des travaux 
réalisés autour ou à partir des logiques tem- 
porelles, nous avons travaillé dans plusieurs 
directions. Tout d’abord la réalisation d’un 
démonstrateur basé sur la méthode des 
tableaux sémantiques pour diverses logi- 
ques propositionnelles temporelles, ainsi 
qu’une nouvelle implantation de MOLOG en 
Prolog II. D'autre part, nous avons mis en 
place l’ensemble des opérateurs temporels 
des logiques ITL, LTTL, et de Allen afin de 
disposer d’un outil de test de ces différentes 
approches, une application à la gestion des 
processus concurrents a été faite. 

e RAISONNEMENT DANS UN UNIVERS 


MULTI-AGENTS 
Un tel univers peut se représenter par un 


modèle multi-modal associant le temps :4 


(pour représenter l’évolution) et les connais- 
sances des différents agents. Un résolveur de 
problèmes sur cet univers est en cours 
d'étude et l'approche retenue est la mise en 
place de stratégies de déduction sur la 
méthode des tableaux sémantiques. 


Organismes LS - ENSM. 
CER de Mathématiques 1, rue de la Noë 
Esplanade de la Paix 44072 Nantes cedex 03 
Université de Caen à 40371600 
14032 Caen Cedex 

Æ 31948140 

LS Toulouse 

Université Paul-Sabatier 

118, route de Narbonne 

41077 Toulouse 

e 61556763 
Collaborations 
industrielles 


PROJET ALPES (P973 DU PROGRAMME 
ESPRIT) 

Le thème de recherche du projet Alpes 
(Advanced Logic Programming Environ- 
mentS) consiste dans la définition et l’implé- 
mentation d’un environnement de program- 
mation pour Prolog: ALPES possède trois 
niveaux : 

e un niveau central (lié au compilateur) dans 
lequel on définit des primitives permettant 
de définir un système graphique et de modi- 
fier Palgorithme d’unification, 

e un niveau dynamique (lié à l’exécution du 
programme) dans lequel on définit des outils 
pour la modification du contrôle de l’exécu- 
tion des programmes, 

e un niveau statique, auquel se rattache la 
recherche de notre équipe, dans lequel on 
définit des primitives permettant le contrôle 
de types, la mise au point de programmes, 
etc. 

Ce projet est réalisé en collaboration avec 
l'Université de Lisbonne, la société Concep- 
tion et Réalisation Industrielles de Logiciel 
(CRIL), la société BULL, ENIDATA (Bologne, 
Italie), Technische Universität München 
(TUM), le Laboratoire de Recherche en 
Informatique (Orsay). 
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dé Calcul Formel 





Le projet Formel a pour but de concevoir et 
développer des systèmes de calcul formel et 
de les appliquer aux outils de base de génie 
logiciel. Ce projet est formé d’une équipe 
INRIA à Rocquencourt et d’une équipe du 
Laboratoire d'Informatique de l’École Nor- 
male Supérieure (LIENS) travaillant en étroi- 
te collaboration. Cette collaboration a été 
officialisée cette année par la signature d’une 
convention entre les deux organismes, 
Notre projet a pour ambition de développer 
les concepts et les outils de base nécessaires 
à la tâche de conception et de mise au point 
d’un langage de programmation selon tous 
ses aspects de syntaxe, sémantique et déduc- 
tion. 

Une tâche essentielle est de concevoir un 
système formel puissant capable de manipu- 
ler des axiomatisations, spécifiant par exem- 
ple les propriétés algébriques que doivent 
vérifier les opérateurs du langage et des 
définitions, comme par exemple les pro- 
grammes eux-mêmes, les règles de forma- 
tion et de typage de ces programmes, les 
interpréteurs et compilateurs, les règles 
d’inférence de la logique. De plus, un tel 
système doit pouvoir être utilisé comme 
base d’un environnement de programma- 
tion pour le langage, C’est notre thèse qu’un 
environnement de programmation ambi- 
tieux doit s'appuyer sur une machine très 
générale de manipulation de théories ma- 
thématiques. Notre projet s'inscrit donc 
dans un programme à plus long terme 
d'Informatique Fondamentale, vue comme 
cadre d'investigation des Mathématiques 
Constructives. 


L'unité de nos préoccupations est assurée 
par l'existence d’une théorie noyau, le lamb- 
da-calcul, qui se trouve être un outil central 
aussi bien en Logique Mathématique (Théo- 
rie de la Démonstration) qu’en Informati- 
que (Langages Fonctionnels - Sémantique 
Dénotationnelle). Nos recherches s’orien- 
tent selon deux axes principaux : Pimplanta- 
tion des langages fonctionnels et la concep- 
tion d’environnements de preuves. 

Nous décrivons ici sans souci d’exhaustivité 
quelques-unes de nos actions de recherche 
actuelles. 


Actions de recherche 

1 LANGAGES FONCTIONNELS 

Une part importante de l’activité de notre 
projet concerne l’implémentation du langa- 
ge CAML. Il s’agit d’un langage à la fois inter- 
actif, compilé (au vol) et doté d’une structure 
de types génériques permettant la synthèse 
automatique des types par le compilateur. 
Ses domaines d’application sont le Génie 
Logiciel et l'intelligence Artificielle. Cette 
activité de développement peut être vue 
comme application et en même temps sour- 
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ce d'inspiration pour les études théoriques 
sur les langages fonctionnels que nous me- 
nons par ailleurs. 


1.1 DÉVELOPPEMENT DE CAML 

Notre équipe a poursuivi son effort de con- 
ception et d'implantation du langage CAML. 
Cet effort a abouti à la diffusion à l'extérieur 
de la version 2.5 du langage. Cette diffusion, 
effectuée par les membres du projet pour les 
versions en beta-test, fait maintenant l’objet 
d’un accord avec ILOG, qui assure la distri- 
bution, le premier niveau de maintenance, et 
la promotion industrielle. 

Le langage CAML a acquis le statut d’un logi- 
ciel permettant le développement de gros 
systèmes de calcul symboliques grâce aux 
efforts qui ont porté sur les outils de manipu- 
lation de syntaxes (analyseur lexical en 
CAML, grammaires de langages-objets, gé- 
nérateur d’automates), sur les outils de pro- 
duction de documents (Interface Latëx réali- 
sée dans lesprit du système WEB) et sur la 
documentation (Écriture d’un Primer et 
d'un Manuel de Référence). Cet effort de 
développement est mené principalement 
par M. Mauny et P. Weis avec la collabora- 
tion de V. Aponte, A. Laville et D, Rémy. 
De nombreux travaux sont en cours pour 
améliorer l'interface système de CAML 
(interface avec C et X-windows) ainsi que 
son environnement de programmation (édi- 
tion structurée, débogage symbolique, com- 
pilation séparée) et pour étendre le langage 
vers la programmation logique et la pro- 
grammation orientée objets. 


1.2THÉORIE DES LANGAGES FONCTIONNELS 
Les langages fonctionnels se prêtent particu- 
lièrement bien à la description formelle pour 
leur typage ou leur sémantique et nous 
avons pu pousser très loin cette formali- 
sation avec la machine catégorique (CAM) 
décrite par G. Cousineau et P.-L, Curien. 
Elle permet de décrire de façon fine un mé- 
canisme de production de code machine 
pour les programmes fonctionnels. C’est sur 
cette machine virtuelle qu’est bâtie limplé- 
mentation de CAML. 


Cette approche a trouvé son prolongement 
dans les travaux d'Yves Lafont sur la machi- 
ne linéaire, Celle-ci s’appuie sur la Logique 
Linéaire de Jean-Yves Girard dans sa ver- 
sion intuitionniste et présente par rapport à 
la CAM l'intérêt supplémentaire de prendre 
en compte d’un point de vue théorique les 
problèmes d’allocation mémoire. D’une 
façon plus générale, il semble bien que la Lo- 
gique Linéaire soit porteuse d’applications 
informatiques qui vont bien au-delà des lan- 
gages fonctionnels et qu’elles permettent de 
rendre compte de phénomènes tels que le 
parallélisme et la bi-directionnalité des 
transferts d’information. Cette orientation 
est actuellement explorée par Ÿ. Lafontet V. 
Danos. 
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Du point de vue du typage, nous étudions 
différentes possibilités pour introduire la 
notion d’inclusion de types à l’intérieur du 
polymorphisme afin de pouvoir prendre en 
compte la notion d’héritage des langages 
orientés objets. 

Enfin, un effort particulier a été porté sur les 
problèmes liés à l’évaluation paresseuse des 
langages fonctionnels et en particulier sur la 
possibilité d'effectuer le filtrage de façon 
paresseuse. À, Laville a obtenu des résultats 
qui font progresser ce domaine de facon 
significative, 


2 ENVIRONNEMENTS DE 
SPÉCIFICATION ET DE PREUVES 
L'outil méthodologique fondamental pour 
ce thème est une correspondance (dite de 
Curry-Howard), qui relie la notion de type 
(resp. programme) à la notion de proposition 
(resp. preuve). Ceci pèrmet de guider la con- 
ception de types d’un langage de program- 
mation suivant des critères logiques permet- 
tant leur utilisation en tant qu’assertion, Un 
programme bien typé est alors un program- 
me correct vis-à-vis de ses spécifications. De 
plus, on peut voir le programme lui-même 
comme une traduction de la preuve de 
cohérence des types ce qui permet d’envi- 
sager de faire de la synthèse de programme 
par des méthodes de démonstration auto- 
matique, 


2.1 LE CALCUL DES CONSTRUCTIONS 

Les recherches sur la conception d’environ- 
nements de preuve se sont poursuivies 
autour du Calcul des Constructions proposé 
par Th. Coquand et G. Huet. Une version 
CAML plus efficace a été implantée par 
G. Huet, autour d’un noyau de “Machine 
Constructive” particulièrement compact, Cet- 
te machine manipule des environnements 
de types et valeurs interdépendants, permet- 
tant de construire de manière homogène des 
types, des propositions logiques, des preuves 
formelles, des spécifications algorithmiques, 
des programmes, des preuves de correction 
de ces programmes, etc. Un nouvel aigorith- 
me de vérification d'égalité de types, qui pro- 
cède autant que possible de manière inten- 
tionnelle (c’est-à-dire sans expliciter inutile- 
ment la définition des constantes), a permis 
des performances tout à fait satisfaisantes 
pour le développement de preuves interacti- 
ves. Ceci nous a permis d’abandonner le dé- 
veloppement de la version C du Calcul, qui 
ne donne qu’un gain d'efficacité marginal, 
amplement compensé par les possibilités su- 
périeures qu'offre CAML en tant que méta- 
langage interactif. 

2.2 SYNTHÈSE DE PREUVES 

Dans le cadre du Calcul des Constructions, 
Thierry Coquand a travaillé sur l’implanta- 
tion d’une méthode de preuve automatique 
de lemmes. Cette méthode s'inspire essen- 
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tiellement de la méthode des tactiques, du 
système de preuves de programmes LCF 
développé aux universités d’Edimbourg et 
de Cambridge, 


2.3 EXTRACTION DE PROGRAMMES 

On peut utiliser le Calcul des Constructions 
pour le développement de programmes. En 
effet, ce formalisme permet le codage de 
preuves intuitionnistes d’ordre supérieur et 
la preuve intuitionniste qu’une spécification 
est un À-terme que l’on peut voir comme un 
programme. Ce programme termine tou- 
jours et contient de manière interne sa preu- 
ve de correction. 


On aimerait parfois écrire des programmes 
qui ne terminent pas à priori, mais dont on 
prouve par ailleurs la terminaison. Christine 
Paulin a proposé une modification du Calcul 
des Constructions pour résoudre ce type de 
problèmes, On distingue explicitement le 
langage de programmation, le langage de 
preuve et le langage de développement de 
programme. On prouve alors (grâce à la défi- 
nition d’une notion de réalisabilité pour ce 
calcul) qu’une preuve d’une spécification 
(ie. un terme représentant le développe- 
ment d’un algorithme) permet d'obtenir un 
programme ainsi qu'une description des 
propriétés satisfaites par ce programme. 
Un prototype de ce système a été réalisé en 
CAML à partir du système usuel des Cons- 
FUSION et permet l'étude pratique d’exem- 
ples. 


Actions industrielles 


Notre langage CAML est diffusé par la so- 
ciété ILOG. 

Nous sommes en négociation avec le Centre 
de Recherches Bull en vue d’une convention 
de collaboration sur le thème “Programma- 
tion déclarative”, 

La Société Hewlett-Packard a mis à notre 
disposition des postes de travail dans le cadre 
d’un premier contact en vue d’une collabora- 
tion. 

F. Fages est actuellement en détachement 
au Laboratoire de Recherches Thomson- 
CSE. 

À. Suarez a quitté le projet au 1° octobre 87 
pour rejoindre le Centre de Recherches PRL 
de DEC. 


Actions européennes 


Nous participons à une action du program- 
me “Stimulation”. 
Notre projet est engagé dans trois proposi- 
tions de projets pour la deuxième phase 
d’ESPRIT dont deux au titre du programme 
“Basic Research”. 
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Diffusion des résultats 


Les résultats obtenus par l’équipe sont large- 
ment diffusés dans des colloques nationaux 
et internationaux et dans des publications, 
CAML est maintenant distribué par la société 
ILOG. 

G. Huet a organisé un “Institute on Logical 
Foundations of Functional Programming” à 
PUniversité du Texas à Austin en juin 1987, 
dans le cadre de la “Year of Programming” 
de l’Université de Texas. Cet Institut a con- 
sisté en un cours de deux jours, enseigné par 
G. Huet et G, Cousineau, et un séminaire de 
recherche de trois jours, auquel on participé 
de nombreux spécialistes du domaine. Les 
actes en seront publiés chez Addison-Wesley. 
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Génie logiciel: 
“Environnements 
de Programmation" 


Le Pôle “Environnements de Program- 
mation” regroupe les principales équi- 
pes de recherche françaises dans le 
domaine du Génie Logiciel. Il s'agit là 
d'un domaine de recherche très actif, 
dont les applications industrielles sont 
à la fois nombreuses et importantes. Il 
est vrai que dans ce domaine les enjeux 
— y compris économiques — sont de taille, puisqu'il s'agit de 
maîtriser la production de logiciels, dont plus personne ne 
méconnaît la part croissante dans tout système informatique. Il 
n'est donc pas étonnant de constater que les liens entre les 
équipes participant à ce pôle et le tissu industriel national et 
européen sont très nombreux. Ces collaborations entre cher- 
cheurs et industriels ont souvent lieu dans le cadre de projets 
ESPRIT (COMETT, GIPE, FORMETOO, METEOR, REPLAY, TOO- 
LUSE), mais sont aussi concrétisées par des contrats de 
recherche et des boursiers communs recherche/industrie. 





La maîtrise de la production de logiciels ne peut s'envisager 
qu'au travers d'une nécessaire formalisation de cette produc- 
tion, Cette réalité, affirmée depuis longtemps par les cher- 
cheurs, est aujourd'hui de plus en plus reconnue par les indus- 
triels eux-mêmes. Il est donc indispensable, même dans un 
domaine en apparence aussi concret que celui de la produc- 
tion de logiciels, de poursuivre des recherches fondamentales 
sur les différents formalismes qui per- 
mettront de mieux maîtriser la produc- 
tion de logiciels complexes, et ceci 
durant toutes les étapes du cycle de vie 
du logiciel. À cet égard la qualité des 
travaux réalisés par les équipes partici- 
pant au Pôle “Environnement de Pro- 
grammation” est attestée par de nom- 
breuses publications dans des revues et 
des conférences internationales de pre- 
mier plan. Mais ces recherches de 
nature fondamentale doivent aussi être 


: 





accompagnées de développements de 
prototypes qui permettent de valider les 
résultats obtenus, et constituent égale- 
ment une phase préparatoire au trans- 
fert industriel. Dans ce domaine la pro- 
duction des équipes du Pôle “Environne- 
ment de Programmation” est très impor- 
tante et la plupart des systèmes prototy- 
pes rédlisés font l'objet de valorisations 
ou sont diffusés dans les principaux cen- 
tres de recherche français et étrangers. 





L'étude des langages, méthodes et outils de spécification for- 
melle constitue un thème central de recherche pour la plupart 
des équipes impliquées dans le Pôle “Environnement de Pro- 
grammation”. Ce thème est étudié sous différents aspects (les 
types abstraits algébriques constituant le facteur unificateur), 
et parmi les résultats obtenus il faut citer les langages de spéci- 
fication LPG et PLUSS, les environnements de spécification ASS- 
PEGIQUE, OASIS, SACSO. Ces travaux sont accompagnés de 
recherches sur les méthodes de spécification (projets ASSPRO 
et MAYDAY) et sur l'impact des spécifications formelles sur les 
différentes étapes du cycle de vie du logiciel, comme la con- 
ception de programmes (projets CPAO, LPG et MAYDAY/), le 
prototypage (projets ASSPRO et LPG), le test de logiciels (projet 
ASSPRO), la réutilisation de logiciels (projets ASSPRO et CPAO). 
Un second thème de recherche est la manipulation symboli- 
que de programmes : l'objectif poursuivi est de savoir dériver 
un environnement de programmation 
interactif à partir d'une description de la 
sémantique du langage de program- 
mation et permettre ainsi le maintien de 
la cohérence des programmes au tra- 
vers des transformations effectuées 
{projet CROAP, système CENTAUR). 
Enfin, un dernier thème de recherche, 
plus récent mais très prometteur, porte 
sur l'étude et la réalisation d'outils pour 
la génération d'interfaces graphiques 
(projets ASSPRO et CROAP). 
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ASSPRO MOTS CLES 


ASSPEGIQUE (environnement/ 
atelier de génie logiciel) 

bases de données pour génie logiciel 
Cigale (ASSPEGIQUE) 
environnements de programmation 
génération d’interfaces 

génie logiciel 

GRAFFITI (générateur d’interfaces) 
interface homme-machine 

langage de spécification 
METAGRAF (outils de manipulation de réseaux) 
méthodes de spécification 

PLUSS (langage de spécification) 
preuve de spécifications 
programmation assistée 
prototypage 

réseaux de Petri 

réutilisation des programmes 

Reve (environnement de déduction 
automatique) 

SADT (méthode de spécification) 
spécifications algébriques 
spécifications formelles 
spécifications par types abstraits 
stratégies de test 

tests d'intégration 

WISH (shell iconique pour Unix) 
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Assistance 





Le projet ASSPRO (ASSistance à la PROgram- 
mation) a pour objectifs essentiels l'étude 
des méthodes et des moyens qui permettent 
de mieux appréhender ce qu’il est convenu 
d'appeler la “première phase du cycle de vie 
du logiciel”, c’est-à-dire les étapes de con- 
ception, de réalisation et de validation du 
logiciel. Les méthodes liées aux spécifica- 
tions formelles sont systématiquement utili- 
sées au cours de ces différentes étapes. En 
particulier, les techniques relevant de l’ap- 
proche algébrique, ou si lon préfère des 
types abstraits algébriques, sont étudiées et 
mises en application. 


De façon plus précise, on peut décomposer 
les travaux menés dans le cadre du projet 
ASSPRO selon trois axes qui sont : 

e l'étude des langages, méthodes et outils de 
spécification formelle, 

e l'impact des spécifications formelles sur 
différentes étapes du cycle de vie du logiciel, 
notamment les techniques de prototypage, 
la réutilisation du logiciel, le test de logiciel, 
e l'étude et la réalisation d’outils graphiques 
pour le Génie Logiciel. 





Ces travaux conduisent à la réalisation de 
prototypes et sont en partie menés en colla- 
boration d’une part avec d’autres équipes de 
recherche françaises et étrangères (projets 
EURECA & ALGO, Université de Passau en 
RFA, Equipe de J. Guttag au M.LT.), 
d'autre part avec des industriels (C.G.E, 
Matra, S.F.G.L., C.N.ES., Hewlett-Packard, 
Sema-Metra), notamment dans le cadre du 
projet ESPRIT METEOR. 





Le langage de 
spécification PLUSS 

et son environnement 
ASSPEGIQUE 


Les travaux relatifs aux langages, méthodes 
et outils de spécification formelle associent 
étroitement des considérations d’ordre pra- 
tique et des considérations d’ordre théori- 
que. En effet, la spécification formelle de 
logiciels de grande taille, devant satisfaire 
certaines contraintes de robustesse ou de fia- 
bilité (par exemple, les logiciels téléphoni- 
ques, les systèmes embarqués ou un système 
d'exploitation comme Unix), nécessite cer- 
taines extensions de la théorie des types abs- 
traits algébriques classiques, lesquelles po- 
sent des problèmes sémantiques complexes. 


Ainsi, la spécification d’un système de taille 
importante ne peut être considérée comme 
un tout, mais doit au contraire être structu- 
rée en unités plus petites. De plus, une meil- 
leure structuration facilite la réutilisation de 
spécifications existantes, Il faut donc dispo- 
ser d'outils adéquats pour structurer et 


la programmation 


modulariser les spécifications formelles. L’ob- 
jet du langage de spécification que nous 
développons, PLUSS (Proposition pour un 
Langage Utilisant des Spécifications Struc- 
turées), est précisément d'offrir un certain 
nombre de primitives (enrichissement, para- 
métrisation, renommage, contrôle de la visi- 
bilité) permettant de structurer et de compo- 
ser des spécifications algébriques, qui peu- 
vent être génériques. Par ailleurs, la spécifica- 
tion d’un système de taille importante est un 
processus complexe, et il est important de 
pouvoir prendre en compte au niveau du lan- 
gage de spécification les différentes étapes 
du développement de la spécification. C’est 
pourquoi le langage PLUSS permet de distin- 
guer entre des spécifications achevées (les 
specs), dont la signification ne doit plus être 
remise en cause (leur implémentation étant 
éventuellement en cours), et des spécifica- 
tions en cours de conception, encore incom- 
plètes (les sketchs et les drafts). Le langage 
PLUSS permet donc à la fois d'exprimer des 
spécifications modulaires et le développe- 
ment de ces spécifications (grâce à des primi- 
tives permettant de convertir des spécifica- 
tions en cours de conception en spécifica- 
tions achevées), Enfin, il est important de 
noter qu’un gros effort a été réalisé pour 
améliorer la lisibilité des spécifications for- 
melles écrites en PLUSS. 


Les langages et les méthodes de spécifica- 
tion formelle ne sont utilisables que s’ils sont 
accompagnés d’un ensemble d'outils facili- 
tant leur mise en œuvre. C’est dans ce but 
que nous développons l’environnement de 
spécification ASSPEGIQUE (ASsistance à la 
SPEcification alGébriQUE), qui est un véri- 
table “laboratoire de spécification” intégrant 
divers outils d’aide à Pécriture, l'analyse et 
l'utilisation des spécifications algébriques. 
Dans la conception de l’environnement 
ASSPEGIQUE, un soin particulier a été ap- 
porté, d’une part à l’aspect modulaire des 
spécifications et à la réutilisation des spécifi- 
cations, d'autre part à la facilité d'emploi, à la 
flexibilité de l’environnement et à l'interface 
avec l'utilisateur. Les outils disponibles dans 
l’environnement de spécification ASSPEGI- 
QUE comprennent un éditeur dirigé par la 
syntaxe, un outil d'intégration de modules 
de spécification, des outils d'évaluation sym- 
bolique, des outils de preuve, un outil d’as- 
sistance à l'implémentation de spécifications 
en packages Ada, et des passerelles vers les 
logiciels Reve et Slog. Tous ces outils sont 
accessibles via une interface plein-écran, 
multi-fenêtres et accèdent à une bibliothè- 
que de spécifications par un outil spécifique 
chargé du maintien de la cohérence de cette 
bibliothèque. Un composant essentiel de 
l'environnement est le logiciel Cigale, un 
système pour la construction incrémentale 
de grammaires et Panalyse d'expressions : 
Cigale a été spécialement conçu pour per- 
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mettre de définir les opérations avec une 
syntaxe flexible et pour prendre en compte Ia 
surcharge d’opérations et la conversion 
implicite de types, facilités qui concourrent 
grandement à la lisibilité des spécifications. 


Sur un plan plus théorique, les travaux que 
nous menons sur les types abstraits algébri- 
ques portent principalement sur la définition 
de la sémantique du langage PLUSS, sur les 
extensions nécessaires pour augmenter le 
pouvoir d’expression des spécifications algé- 
briques (prise en compte des erreurs, des 
valeurs indéfinies et des traitements d’ex- 
ception, possibilité de spécifier des accès 
concurrents à des données partagées), et sur 
les aspects opérationnels des spécifications 
algébriques (théorie de la réécriture condi- 
tionnelle, compilation de systèmes de réécri- 
ture, complexité algorithmique des systè- 
mes de réécriture), 


Les perspectives de recherche pour cet axe 
concernent essentiellement la poursuite des 
travaux sur le langage PLUSS, notamment au 
travers de diverses études de cas, et la réalisa- 
tion d’une nouvelle version de l’environne- 
ment ASSPEGIQUE permettant de prendre 
en compte les récents développements du 
langage de spécification. 


Par ailleurs, de façon complémentaire à 
l'évolution de PLUSS vers un langage de 
développement de spécifications, des études 
sont menées pour la conception de bases de 
données pour le Génie Logiciel. Ces études 
sont basées sur le modèle dérivation-verrouil- 
lage et dans un premier temps, une base de 
données mémorisant les informations con- 
cernant le développement de spécifications 
est à l'étude, pour une intégration au sein de 
l’environnement ASSPEGIQUE. 


La réutilisation 

de logiciels 

La réutilisation de logiciels est pratiquée 
actuellement sur des bases empiriques, et 
dans des domaines bien précis (parexemple, 
des bibliothèques d’algorithmes de calculs 
numériques). Depuis longtemps, on sait que 
la clé de toute approche générale à ce pro- 
blème est lutilisation de spécifications for- 
melles du fogiciel à réaliser et des compo- 
sants logiciels éventuellement réutilisables. 


C’est sous cet angle que nous étudions dans 
quelle mesure les spécifications algébriques 
peuvent être utilisées pour la réutilisation du 
logiciel. Nous avons déjà obtenu des résui- 
tats prometteurs, par exemple le résultat sui- 
vant : 

Soit une spécification SP' d’un programme à 
réaliser et soit une spécification SP d'un pro- 
gramme existant. Le programme correspon- 


Organisme 

LRI. Université d'Orsay 
université de Paris Sud 

91405 Orsay 

Æ ()67416629 & 69416628 


dant à la spécification SP est réutilisable pour 
la spécification SP's'il existe une extension SPI 
de SP qui est équivalente, à des renommages 
près, à un enrichissement de SP' (intuitive- 
ment, on ajoute certaines fonctions à SP et 
on en oublie d’autres). 

Les notions de renommage et d’enrichisse- 
ment étaient déjà connues. L'innovation 
tient à la notion d’extension et à la sémanti- 
que mathématique qui en est donnée : cela. 
permet de définir une modularité des spéci- 
fications compatible avec celle des program- 
mes. On obtient ainsi un critère théorique 
indiquant si l’on peut composer le pro- 
gramme associé à SP et le programme corres- 
pondant à l'extension sans que les choix de 
programmation interfèrent. Cette formalisa- 
tion permet de plus de définir précisément 
des notions de réutilisation efficace et de 
réutilisation non efficace. 


Les perspectives dans ce domaine sont évi- 
demment très prometteuses. Dans un pre- 
mier temps, il faut étudier comment cette 
formalisation de la notion de réutilisation 
peut être étendue pour prendre en compte 
toutes les primitives de structuration des 
spécifiques algébriques, et notamment la 
paramétrisation, A terme, ces recherches 
doivent déboucher sur la définition de bases 
de composants logiciels réutilisables. 


Le test de logiciel 


Une théorie du test de logiciels basée sur des 
spécifications formelles a été proposée en 
1982 par Luc Bougé et appliquée aux spécifi- 
cations algébriques. Ces travaux ont été 
poursuivis depuis, d’abord aux Laboratoires 
de Marcoussis, puis dans le cadre du projet 
ASSPRO, et reposent sur les idées suivantes : 
e Les axiomes d’une spécification algébri- 
que étant constitués d’égalités (éventuelle- 
ment conditionnelles) entre deux termes, on 
peut soumettre au programme sous test les 
parties droite et gauche de ces égalités (pour 
des instances ”bien choisies”, cf ci-dessous), 
Le succès ou l’échec d’un tel test est alors 
déterminé en vérifiant si les deux résultats 
obtenus sont égaux. La spécification joue 
donc un rôle d’oracle, puisqu'elle permet de 
décider du résultat des tests. 

e La structure de la spécification peut être 
utilisée pour guider le choix des valeurs de 
test. Par exemple, en introduisant une 
mesure de complexité sur les types définis, 
on peut ne tester que des valeurs de com- 
plexité inférieure à une certaine borne. On 
peut aussi donner des valeurs aléatoires aux 
variables de types prédéfinis (déjà testés). On 
dit que l’on fait respectivement des hypothè- 
ses de régularité sur les types définis et d’uni- 
formité sur les types prédéfinis. Ces hypo- 
thèses permettent de sélectionner de façon 
pertinente des jeux de tests finis et de taille 
raisonnable. 
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Assistance à la programmation. 


Récemment, des notions de couverture de 
test pour des spécifications algébriques ont 
été définies. Ces critères de couverture 
induisent des stratégies de test où les jeux de 
tests successifs tendent vers une limite qui 
est une preuve de la correction du pro- 
gramme. 


Ces stratégies de test peuvent être exprimées 
formellement et automatisées partiellement 
au moyen de démonstrateurs de théorèmes. 
Cette automatisation est bien évidemment 
l'objectif premier de nos recherches sur le 
test de logiciels. Pour l'instant nos expérien- 
ces sont faites en utilisant des systèmes de 
programmation logique existants, et diver- 
ses stratégies ont été implémentées en Slog 
eten Quintus Prolog. Un exemple non trivial, 
les arbres binaires de recherche, a été traité 
complètement selon ces stratégies. Une éva- 
luation de la qualité des tests obtenus par 
injection de fautes dans les programmes est 
en Cours. 


Les recherches actuelles portent sur deux 
points : 

e La définition de nouvelles stratégies, en 
particulier pour les types bornés. Ces types 
sont traditionnellement testés de manière 
spécifique (tests systématiques des limites) 
et on retrouve cette spécificité au niveau 
théorique : les stratégies classiques s’appli- 
quent mal (hypothèses peu réalistes). 

e La réalisation d’un environnement de pro- 
grammation logique adapté à la production 
de jeux de test à partir de spécifications algé- 
briques. 


Ces travaux devraient conduire à une colla- 
boration avec EDF. 


Le protoiypage 

et le test 

d'intégration 

Lors de la conception de systèmes com- 
plexes, chaque module doit être testé indivi- 
duellement, ainsi que l'intégration des 
modules connectés entre eux. Les techni- 
ques de prototypage peuvent considérable- 
ment aider les tests d'intégration. Partant 
d’une spécification formelle hiérarchique et 
modulaire, les parties exécutables de celle-ci 
peuvent être utilisées comme un prototype 
du système. On peut ensuite progressive- 
ment remplacer les modules de spécifica- 
tions par leur implémentation. L’exécution 
dun tel système, où l'intégration est par- 
tielle, nécessite des techniques d'évaluation 
mixte combinant la réécriture (pour les 
modules uniquement spécifiés) et l'évalua- 
tion directe (pour les modules implémen- 
tés). Les problèmes liés à l'étude de telles 
techniques d’évaluation mixte sont en cours 
d'évaluation. 


L'étude et la 
réalisation d'outils 
graphiques pour 

le génie logiciel 

La banalisation des stations de travail mu- 
nies de possibilités graphiques, de moyens 
de désignation et de systèmes de multi-fené- 
trage permet de mieux prendre en compte 
les problèmes d'interface utilisateur. Nos 
travaux portent sur la description et le déve- 
loppement d’interfaces graphiques adapta- 
bles et facilement réutilisables, et s’appuient 
sur nos réalisations précédentes, PETRI- 
POTE (un outil pour l'édition et la simulation 
graphique de réseaux de Pétri, qui a été uti- 
lisé au L.R.L. et largement diffusé dans diffé- 
rents laboratoires de recherche européens) 
et le terminal STEP (développé en collabora- 
tion avec les laboratoires de Marcoussis sous 
contrat CNET, et actuellement commercia- 
lisé par la société AMAIA). 

Nous étudions essentiellement les interfaces 
graphiques mettant en œuvre des objets 
structurés, comme par exemple des réseaux 
de Pétri, des schémas de programme, des 
types de données, des diagrammes SADT, 
etc. Dans chaque cas, l'interaction avec l’uti- 
lisateur doit être faite directement au niveau 
de la représentation graphique externe des 
objets manipulés, même si l'interface gra- 
phique doit parallèlement mettre à jour la 
structure interne correspondante, Les pro- 
blèmes de performance sont évidemment 
cruciaux en ce domaine. 


Nous avons développé un méta-modèle 
d'interaction graphique, UFO (User-Friendly 
Objects), centré sur la notion d’objet, per- 
mettant de développer rapidement des inter- 
faces graphiques sophistiquées. Au-dessus 
d'UFO sont développés deux types d’outils : 
e METAGRAF, qui permet de définir la repré- 
sentation de réseaux complexes et leur 
manipulation, 

e GRAFFITI, qui permet la définition graphi- 
que interactive de la structure de contrôle de 
l'interface (menus, boîtes de dialogues, etc.) 
etla définition interactive des liens entre l’in- 
terface et l'application à l’aide de points d’en- 
trée et de valeurs actives. 


GRAFFITI est lun des tout premiers vrais 
générateurs d'interface qui soit à la fois réel- 
Jement interactif et qui permette la construc- 
tion d’interfaces adaptables par l'utilisateur. 
Contrairement à la génération de compila- 
teurs à partir de la description de la syntaxe et 
de la sémantique d’un langage, l’aspect inte- 
ractif dans la génération d’interfaces est cru- 
cial car il permet un prototypage rapide et 
une construction facile de l'interface. 

UFO et GRAFFITI sont utilisés pour réaliser 
wWISH, un shell iconique pour Unix. WISH 
gère la représentation d’entités Unix telles 











que fichiers, directories, processus, utilisa- 
teurs, machines, etc. sous forme d’icônes, en 
associant aux actions de lutilisateur (dépla- 
cements, ouverture, etc.) une sémantique 
dépendant du type de l'icône mise en jeu. 
WISH permet de réaliser de manière simple 
et intuitive la plupart des opérations effec- 
tuées habituellement à l’aide du shell Unix 
standard, et il est paramétrable par l’utilisa- 
teur. 


Les objectifs à moyen et long terme sont 
l'utilisation des outils mentionnés ci-dessus 
dans Le cadre d’applications de plus grande 
taille, comme l’environnement de spécifica- 
tion ASSPEGIQUE, un environnement de 
programmation parallèle, etc. Ceci nécessite 
la définition de nouvelles abstractions, l’ex- 
tension du modèle de communication entre 
l'interface et Papplication et l'intégration des 
différents outils au sein d’un atelier de cons- 
truction d’interfaces, 
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MAIDAY 
Outils et Méthodes 






L'objectif général du projet MAIDAY est de 
contribuer à un travail de réflexion sur la spé- 
cification de problèmes et la construction de 
programmes, et de développer des outils 
dans ce domaine. 

Il est notoire que le coût de développement 
et de maintenance des systèmes informati- 
ques augmente. Des études ont montré que 
si le coût de maintenance provient en partie 
des erreurs de programmation, il résulte sur- 
tout d’une mauvaise description des besoins 
exprimés par les demandeurs : c’est-à-dire 
d’une mauvaise spécification. 

Si l'étape de spécification apparaît alors 
comme importante, voire primordiale, il 
n’est pas encore réaliste de penser qu’il suffit 
de spécifier un problème informatique pour 
que sa construction effective en découle de 
façon automatique. Notre projet étudie, au 
moins en partie, les étapes de spécification et 
de programmation avec les objectifs sui- 
vants : 


e Mieux comprendre les mécanismes de 
base de la construction, en concentrant 
notre attention sur lenchaînement des 
choix cruciaux qui conduisent à une spécifi- 
cation et à un programme. 


e Concevoir des outils d’aide puissants : 

- à la spécification, 

= à la programmation directe (à partir d’un 
énoncé informel) ou indirecte (à partir d’une 
spécification formelle par mise en évidence 
de techniques de transformation). 


e Réaliser des maquettes de ces outils en uti- 
lisant, de façon si possible novatrice, des 
outils logiciels de recherche, leur fournissant 
ainsi une base d’expérimentation. 


Schématiquement, à côté de la définition de 
Jangages de spécification et de programma- 
tion, il convient de définir des formalismes 
permettant d'exprimer des dérivations de 
spécifications et de programmes, ainsi que 
des schémas de dérivation (parfois appelés 
tactiques ou stratégies). Cette approche pré- 
cise et généralise les diverses études sur la 
méthodologie de la programmation, trop 
souvent objet de descriptions approximati- 
ves et imprécises. Elle permet de dépasser le 
dogmatisme des approches descendantes en 
autorisant de mêler, selon le contexte, diffé- 
rents points de vue : décomposition hiérar- 
chique, recomposition ascendante, appro- 
che guidée par les objets. Ce point de vue 
permet de considérer une méthode comme 
un enchaînement particulier de décisions de 
construction, ainsi, un choix entre de tels 
enchaînements devient possible. Les consé- 
quences de cette approche sont nombreu- 
ses : 

e Aide à la documentation interne. La suite 
des décisions de construction est un élément 
capital d’aide à la compréhension du rôle et 
de la structure d’un logiciel. 


pour Spécifier et Construire 


e Aide à la modification. L’adaptation d’un 
logiciel à une évolution du cahier des char- 
ges initial va consister à remettre en cause 
certaines décisions de construction. 


© Aide à la réutilisation. Plutôt que de géné- 
raliser a priori un problème pour le faire 
dépendre de paramètres en vue d’en fournir 
ultérieurement plusieurs instances, il est 
économiquement plus raisonnable de ne 
résoudre que le problème posé et de réutili- 
ser non pas le logiciel associé, mais la dériva- 
tion qui la fourni. 


La mise en œuvre de ces idées nécessite, 
d'une part, l’utilisation ou l'adaptation de 
langages permettant d’exprimer spécifica- 
tions et programmes, d’autre part, la défini- 
tion de langages de description de dériva- 
tions et de raisonnements. Ces définitions et 
adaptations se concrétisent par la réalisation 
de maquettes logicielles permettant de vali- 
der les hypothèses émises. Fondés sur les 
idées précédentes, trois axes qui donnent 
lieu à la réalisation de maquettes, se sont 
dégagés : construction raisonnée d’une spé- 
cification à partir d’un cahier des charges, 
construction raisonnée d’un algorithme à 
partir d’un cahier des charges, construction 
interactive d’un programme fonctionnel à 
partir d’une spécification exprimée en logi- 
que clausale. 


Sacso : assistance 
à la spécification 


Le but de notre projet est l’étude des méca- 
nismes mis en œuvre lors de la construction 
de spécifications. La spécification d’un sys- 
tème complexe ne s’effectue pas de manière 
linéaire mais plutôt par une succession d’éta- 
pes d’enrichissement, de validation, d’opti- 
misation ou de modification de la spécifica- 
tion en cours de construction. En reprenant 
les idées développées en introduction, nous 
distinguons trois niveaux dans Pétape de 
construction d’une spécification : le produit 
ou spécification, le processus de construc- 
tion de spécifications et les stratégies ayant 
conduit à l'élaboration de la spécification. 
Notre travail a essentiellement porté sur 
l'étude des deux premiers niveaux et à leur 
mise en œuvre dans le logiciel SACSO, sys- 
tème d’aide à la construction et à la valida- 
tion de spécifications, [fin87]. 


1. CONTEXTE DU TRAVAIL 

Une spécification décrit les besoins expri- 
més par les utilisateurs, en particulier les 
fonctionnalités attendues du système et l’in- 
teraction entre le système informatique et 
son environnement. Les spécifications con- 
sidérées sont définies formellement de 
manière constructive par enrichissements 
successifs à partir de spécifications de base 
disponibles dans une bibliothèque. Il est 
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important de préciser que le système et ses 
outils sont prévus pour travailler sur des spé- 
cifications incomplètes, c’est-à-dire en cours 
d'élaboration [sou86]. Le langage utilisé est 
un langage basé sur les types abstraits algé- 
briques, L'étude d’une sémantique formelle 
de ce langage est en cours. Une validation 
des idées et du système a été réalisée sur des 
exemples réels dans le cadre d’une collabo- 
ration industrielle [sil87]. Le système est 
actuellement disponible sur SUN. I est écrit 
en LeLisp-Ceyx et interfac’e avec X-Win- 
dows. 


2. LE PROCESSUS DE CONSTRUCTION 
Le processus de construction suivi par le spé- 
cifieur fournit une trace rigoureuse de l’acti- 
vité de développement. Elle est essentielle 
pour comprendre, vérifier, maintenir et réu- 
tiliser une spécification. Nous considérons 
un processus de construction comme une 
succession d'étapes, chaque étape corres- 
pondant à l’application d’un opérateur parti- 
culier à la spécification. Nous distinguons 
trois sortes d'opérateurs : 


o Les opérateurs de structuration utilisés 
pour favoriser l’extension et la réutilisation 
de spécifications [lev87]. Ils sont basés sur les 
mécanismes d’enrichissement et de paramé- 
trisation et sont implantés dans le système 
SACSO par l'intermédiaire des fonctions de 
modification, de renommage basées sur la 
relation “utilise”, sur la possibilité de mani- 
puler des définitions incomplètes et de béné- 
fcier des aides et déductions fournies par le 
système, La bibliothèque prédéfinie de types 
de base et de constructeurs de types (ou 
types paramétrés) munis des opérations 
usuelles favorise la modularité et la réutilisa- 
tion de spécifications. 


o Les opérateurs de validation et d’analyse 
utilisés pour vérifier la correction et l’adé- 
quation de la spécification aux besoins des 
utilisateurs et contrôler que les spécifica- 
tions vérifient certaines propriétés. Les opé- 
rateurs d’analyse sont implantés dans 
SACSO par l'intermédiaire d'opérateurs de 
contrôle et d’un langage de requêtes permet- 
tant, à chaque étape de la construction, 
d’avoir des renseignements sur les incom- 
plétudes, les erreurs éventuelles détectées 
par le contrôle de types, ce qui est indéfini, 
utilisé par une entité donnée, non utilisé, etc. 
Nous distinguons deux types d'opérateurs 
de validation : 

— les opérateurs de conversion d’une spécifi- 
cation dans un autre formalisme facilitant la 
communication avec le client. Nous dispo- 
sons d'outils permettant d’extraire des infor- 
mations sur la spécification tels que le 
résumé, la description informelle. La réalisa- 
tion d’outils de visualisation de la spécifica- 
tion dans un modèle relationnel et de visua- 
lisation graphique de [a structure des types 
sont en cours de réalisation. 





Organisme 

CRIN. Université de Nancy 
BP 239 

54506 Vandæuvre-lès-Nancy 
& 83912119 


-les opérateurs de production d’un pro- 
totype exécutable de la spécification. Nous 
disposons d’un interprète travaillant sur des 
spécifications incomplètes et d’un outil de 
prototypage transformant une spécification 
complète et correcte en un programme Lisp. 
e Les opérateurs de restructuration utilisés 
pour éliminer la redondance, favoriser la 
modularité ou simplifier des fragments de 
spécification. Ils sont basés sur la manipula- 
tion de la structure des types [dub87]. Nous 
avons introduit un certain nombre d’opéra- 
teurs prédéfinis, Ïls sont utilisés par exemple 
lors de la conversion dans un autre forma- 
lisme. 


3. PERSPECTIVES 

La description des stratégies [anna86] doit 
permettre d'exprimer les raisons du choix de 
lenchaînement des différents opérateurs 
lors de l'élaboration du processus de cons- 
truction et de fournir des heuristiques d’ap- 
plication de ces opérateurs. Une première 
approche a abouti à [a réalisation du pilote, 
Cette étude se poursuit avec le souci de réu- 
tiliser aussi bien des spécifications que des 
processus de construction. Une étude plus 
fondamentale sur la réutilisation est en 
cours, en particulier avec une recherche de 
critères de comparaison d’opérations et de 
critères d'application de transformations. 
L'étude de la sémantique nous permet de 
préciser Les bases formelles du langage et de 
construire un outil de prototypage plus com- 
plet incluant, outre l'interprète actuel, un 
évaluateur symbolique. 


Maiday : assistance 

à la programmation 
Dans le cadre du projet Maiday, notre travail 
est focalisé sur l’activité de création des pro- 
grammes, Des nombreux résultats des re- 
cherche abordant ce domaine, nous rete- 
nons essentiellement trois points : 

+ l'intérêt des langages applicatifs pour expri- 
mer les programmes. Ils permettent en effet 
de structurer naturellement les algorithmes, 
mais surtout de raisonner formellement sur 
les programmes. 


e la nécessité de fournir au programmeur des 
guides effectifs pour l’assister dans sa 
démarche de création. En effet, la com- 
plexité du passage d’un problème à un pro- 
gramme est telle que la planification de cette 
activité est elle-même un travail complexe. 


© la puissance et la qualité de la technologie 
matérielle et logicielle, En effet, grâce aux 
éditeurs syntaxiques et sémantiques et aux 
environnements, il devient possible d’auto- 
matiser certaines tâches annexes, de contrô- 
ler ou de tester les programmes au cours 
même de leur création. 
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Notre objectifest donc de construire des sys- 
tèmes, suffisamment intelligents, d’aide à 
une programmation raisonnée en intégrant 
en un outil unique les trois points précé- 
dents. Nous sommes convaincus que Peffet 
synergétique résultant de l’intégration estun 
facteur clé pour avancer dans notre domaine 
de recherche. 

Nous avons adopté une démarche expéri- 
mentale consistant à construire des maquet- 
tes logicielles puis à les évaluer, Chaque 
cycle expérimental vise trois buts : acquérir 
une expertise profonde sur les différents 
points, obtenir des critères objectifs de juge- 
ment des différentes techniques (concep- 
tuelles et logicielles) vis-à-vis de la program- 
mation et enfin, mettre en évidence les 
mécanismes fins de l’activité de création de 
programmes. 


1. RÉSULTATS OBTENUS 

Une première maquette, EDME, a été livrée 
en 1984. Elle a été évaluée grâce au travail de 
JM. Hoc qui la utilisée comme support 
pour une expérience en psychologie de la 
planification. 

EDME est un éditeur méthodique d’aide à la 
création d’algorithmes. Nous avons utilisé le 
langage MEDBE comme support d’expres- 
sion, la méthode déductive comme guide 
systématique, et MENTOR-METAL comme 
base d'implantation. Les caractéristiques 
d'EDME sont : 

e une stricte incrémentalité garantissant que 
lalgorithme est À tout moment correct sur 
les plans syntaxiques, contextuels et métho- 
diques. Les différents contrôles sont effec- 
tués par l’éditeur et implantés en MENTOL. 


e une aide à l'utilisateur sous la forme d’une 
construction automatique du texte, d’in- 
férences de textes (déclaration de comp- 
teurs...) et de calculs (objets à initialiser, tra- 
vail restant à faire...) 

+ une ergonomie de l’interaction soignée, en 
particulier par le biais d’un multi-fenêtrage 
sophistiqué. 

s un langage de commande destiné à réduire 
la distance entre les opérations intellectuel- 
les de conception de l'algorithme et les opé- 
rations d'édition. 

L'expérience de J.M. Hoc, destinée à étudier 
les stratégies de planification des program- 
meurs, a consisté à analyser les sessions 
complètes de travail avec EDME d’une quin- 
zaine de professionnels extérieurs au labora- 
toire. 

L'analyse des résultats de cette évaluation a 
mis en évidence les points positifs suivants. 
La conception et la réalisation d’'ÉDME sont 
robustes. Notre hypothèse sur le contenu 
d'un outil d'aide (ergonomie, contrôles, 
inférences, guide systématique, langage de 
commande) a été confirmée, en particulier 
par les temps d'apprentissage très courts et la 
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fourniture d’algorithmes corrects par tous 
les sujets de l’expérience. Un certain nombre 
de difficultés ont été mises en évidence. Leur 
importance est essentielle à notre démarche 
puisqu'elles définissent nos directions de 
travail actuelles. Elles peuvent être regrou- 
pées en trois classes : 


e L'EXPRESSIVITÉ DU LANGAGE. Le langage 
MEDEÉE implanté utilise des types de don- 
nées et des structures de contrôle de trop bas 
niveau vis-à-vis de l’activité de conception. 
L'introduction d’une construction oblige à 
définir immédiatement des détails très fins 
alors que le concepteur souhaiterait travail- 
ler sur un schéma générique, 


oLA NON-LINÉARITÉ DES DÉVELOPPE- 
MENTS. Cet aspect se traduit de deux façons : 
par des remises en cause fréquentes en cours 
de construction et par des changements de 
stratégies de travail. EDME s’est révélé être 
un frein dans ces deux situations. Dans le 
premier cas parce que lincrémentalité 
oblige à oublierle travail remis en cause, dans 
le second parce que la méthode implantée ne 
comporte qu’une stratégie, La leçon à tirer 
est importante car elle concerne moins 
l'outil que l’idée, implicite à toutes les systé- 
matiques de la programmation, qu’un pro- 
gramme peut être construit dans une 
démarche linéaire située dans un cadre uni- 
que. Clairement, cette idée doit êre très for- 
tement nuancée. 


ve LA RÉUTILISATION. Le modèle de dévelop- 
pement supporté par EDME suppose que le 
programme est construit ex nihilo, la réutili- 
sation est vue comme l'emploi sans modifi- 
cation d’un fragment logiciel existant. Il est 
vite apparu que le concepteur travaille sou- 
vent à partir d’une solution existante qu’il 
adapte au problème posé. Dans ce type de 
situations, EDME n’apporte aucune aide. De 
nouveau, la difficulté remonte au plan des 
systématiques car aucune d’elles ne sup- 
porte réellement cette forme de développe- 
ment. 


Depuis 1986, notre travail est donc orienté 
vers l’étude et la résolution de ces difficultés. 


2. AIDE A LA CONCEPTION DIRECTE DE 
PROGRAMMES 

Ce volet du projet traite du problème de l’ex- 
pressivité du langage. Nous y avons adopté 
une démarche pragmatique en introduisant 
dans le langage MEDEE des constructions de 
haut niveau telles que les abstractions de 
types et les itérateurs. Par rapport à EDME, la 
maquette, en phase de conception, per- 
mettra d'étudier une solution à un problème 
important, issu de nos activités pédagogi- 
ques. 

Il apparaît que les langages de programma- 
tion ris à la disposition des utilisateurs occa- 
sionnels ou débutants peuvent être schéma- 
tiquement répartis en deux classes : les lan- 


gages généraux (PASCAL, C), et les langages 
intégrés dits de quatrième génération (MAP- 
PER, Dbase Nil). Nous avons constaté que les 
débutants opposent fortement ces deux clas- 
ses. Dès lors, le passage entre ces deux 
modes d’expression pour concevoir les pro- 
grammes est délicat, de plus, il souffre d’un 
fotal manque de systématique. Selon nous, 
la discontinuité vient du fait que la notion de 
type, fondement actuel de la programmation, 
y est approchée de façon différente : 


e dans les langages intégrés, on utilise direc- 
tement le type via ses opérations de manipu- 
lation. On peut enchaîner des opérations 
mais pas créer de nouveaux types. 


e dans les langages classiques, les types ser- 
vent d’une part à modéliser les objets du pro- 
blème et d’autre part à les implanter en 
machine, 


L'objectif est alors d'obtenir un outil per- 
mettant un passage continu entre ces deux 
formes d’approches. Il offrira donc les possi- 
bilités suivantes : 


econstructeurs de types de haut niveau 
comme PILE ou ARBRE, mais aussi RELA- 
TION et FEUILLE DE CALCUL. 


e modularité et structuration des analyses 
dans les phases de programmation et cons- 
truction automatisée des algorithmes lors de 
lenchaînement manuel de calculs. 


egestion de lintendance par la prise en 
charge des aspects syntaxiques et sémanti- 
ques. ‘ 


e documentation gérée et construite auto- 
matiquement. 


La définition du nouveau langage est main- 
tenant terminée, ainsi que les tests des outils 
comme CEPAGE ou MENTOR-TYPOL desti- 
nés à supporter l'implantation. Nous espé- 
rons disposer d’une maquette en 1988. Nous 
envisageons d’en étudier une mise en 
œuvre au plan industriel, dans le cadre de 
notre participation au projet européen 
COMETT. 
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Le projet LPG : 
un langage 

de spécification 
modulaire 

et générique 


Le processus de construction de logiciel a été 
analysé depuis une quinzaine d’années, et 
ces études ont mis en évidence la nécessité 
de réaliser un développement en phases suc- 
cessives ou itérées allant de la constitution 
du cahier des charges et des spécifications 
fonctionnelles informelles du système à la 
réalisation effective des programmes, en 
passant par les étapes d’architecture ou de 
conception modulaire, de spécifications for- 
melles ou semi-formelles, de prototypage, 
de tests structurels ou fonctionnels, de 
codage, d'intégration, etc. Un certain 
nombre d'outils sont actuellement disponi- 
bles sur le marché pour couvrir quelques- 
unes de ces phases, bien qu’il n’en existe pas 
encore couvrant véritablement le cycle de 
vie complet. Les outils pour la spécification 
dite “semi-formelle” sont assez avancés et 
apportent déjà beaucoup à la phase de con- 
ception et de documentation. Le projet LPG 
vise à expérimenter, à l’aide d’un langage et 
d'outils appropriés, la faisabilité et le champ 
d'application des spécifications formelles, 
que ce soit au niveau de la facilité d'écriture, 
de la lisibilité, de la puissance d'expression, 
de la structuration, des outils d’analyse, de 
validation, de tests, et également dans un 
deuxième temps, d’apprécier la possibilité 
de relier les spécifications formelles aux pro- 
grammes par des processus automatisés et 


de favoriser la réutilisation des composants : 


logiciels, A la lecture de ces objectifs, et en 
regard des moyens limités dont dispose un 
laboratoire universitaire, il est évident que 
nous ne cherchons pas à réaliser un outil de 
type industriel, mais plutôt à fournir une 
maquette dans laquelle la plupart de ces 
points peuvent être expérimentés, l’expé- 
rience venant confirmer ou infirmer l’adé- 
quation du formalisme, du langage et de la 
maquette aux objectifs visés. Notre travail se 
situe donc au stade du pré-développement, 
participant ou étant très en contact avec les 
recherches théoriques qui peuvent être 
menées sur ces sujets. 





Un langage pour la spécification formelle 
doit être fondé sur une sémantique rigou- 
reuse. Les choix que nous avons faits repo- 
sent essentiellement sur les travaux de Zil- 
les, Guttag, Goguen, Thatcher, Wagner, 
Wright relatifs à la spécification algébrique 
des types abstraifs, et sur les travaux de Burs- 
tall, Goguen, Meseguer, Ehrig, Bergstra, 
Wirsing pour la structuration des spécifica- 
tions, la sémantique de la généricité et les 
bases logiques. 


Spécifications formelles 
& prosrammaton 2énérique 







Participants P. Jacquet 

H, Comon D. Lugiez 

P, Drabik ML. Potet 

R. Echahed J.-C. Reynaud 


D'une manière plus précise, notre projet 
repose sur un langage de spécification 
modulaire et générique, permettant la pro- 
grammation fonctionnelle et logique, fondé 
sur la sémantique des clauses de Horn avec 
égalité. Cette sémantique englobe d’une 
manière cohérente la sémantique des clau- 
ses de Horn comme dans PROLOG, et la 


sémantique des types abstraits algébriques . 


avec axiomes équationnels et conditionnels. 
Grâce à cela, l'utilisateur peut décrire son 
problème en terme de types (abstraits), de 
fonctions et de relations. On pense ainsi 
fournir des moyens qui couvrent une large 
classe d'applications. Ce langage expérimen- 
tal, appelé LPG, a été implanté au sein d’un 
“atelier de spécification” qui fournit un 
ensemble d’outils dont nous parlerons plus 
loin. 


Pour écrire de “grosses” spécifications, les 
modules de base doivent pouvoir être définis 
séparément, ou d’une manière hiérarchique 
(un module utilise des modules déjà défi- 
nis), ou encore être composés pour obtenir 
des spécifications complexes. Quelques 
techniques de composition de modules ont 
été proposées dans les langages ou projets 
CLEAR, CAT (Burstall, Goguen), LARCH 
(Guttag, Horning), ACT ONE (Ehrig, Mahr), 
ASF (Bergstra, Heering, Klint), ASL (Wir- 
sing) et au GRECO Programmation : SPRAC 
(CERT Toulouse), PLUSS (M.-C. Gaudel, 
LRI). Notre approche a étudié tout particuliè- 
rement les mécanismes ”d’instanciation” 
d’un module générique (création d’exem- 
plaires). LPG possède un mécanisme de 
paramétrisation très poussé qui facilite La 
structuration et la réutilisation. Dans le 
même ordre d’idées, la preuve de program- 
me générique n’est plus un raisonnement 
spécifique à un programme, mais elle con- 
siste à démontrer un théorème dont on a 
donnéles hypothèses dans la partie formelle. 


Un environnement 
pour écrire 

et manipuler 

des spécifications 

Autour du langage LPG, nous avons réalisé 
des outils qui permettent de manipuler les 
spécifications. Ces outils sont intégrés dans 
un environnement dont une première ver- 
sion a été implantée sur système MULTICS, 
et dont une deuxième version a été réalisée, 
en coopération avec l’université catholique 
de Louvain, sur station SUN, système UNIX, 


Ces outils sont : 


eUN INTERPRÉTEUR DE SPECIFICATIONS, 
BASE SUR UNE MACHINE ABSTRAITE A 
PILE: Ï permet de tester et d’exécuter des 
programmes fonctionnels avec une certaine 
efficacité, car les fonctions de base sont 
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codées directement dans l’interpréteur. De 
plus, la méthode de compilation des fonc- 
tions génériques r’introduit que peu de 
surcoût (à la fois à la compilation et à 
exécution) par rapport aux fonctions non 
génériques. 

e UN RÉSOLVEUR D'EXPRESSIONS LOGI- 
QUES : Une expression logique est une éga- 
lité de termes, ou un prédicat muni de ses 
arguments. Le résolveur, connaissant les 
définitions des opérateurs et prédicats, cal- 
cule les valeurs des variables qui satisfont 
une expression logique donnée. La méthode 
repose sur Palgorithme de résolution de 
Robinson, et sur la relation de “narrowing”. 
Cet outil permet de faire de la programma- 
tion logique en LPG, alors que l’interpréteur 
est dédié à la programmation fonctionnelle. 
e DES ALGORITHMES DE COMPLÉTION DE 
THÉORIES (ALGORITHME DE KNUTH ET 
BENDIX) DANS LE CAS ÉQUATIONNEL ET 
DANS LE CAS INDUCTIF : Comme il a été 
montré par Musser, Huet, Hullot, cet algo- 
rithme permet de démontrer des théorèmes 
dans des théories équationnelles avec cons- 
tructeurs, ou satisfaisant à des conditions 
dites de “complétude inductive”. Des amé- 
liorations et extensions des techniques de 
complétion sont intensivement étudiées au 
CRIN (Nancy). 


e UN ÉDITEUR SYNTAXIQUE: Construit à 
partir du générateur “Cornell Synthesizer” 
(sur version SUN uniquement). 


e UN DÉMONSTRATEUR DE THÉORÈME: 
pour les spécifications ne rentrant pas dans le 
cadre des preuves par complétion, il est 
nécessaire de disposer de démonstrateurs 
interactifs procédant à partir de règles d’infé- 
rence. Sur la version MULTICS, nous avons 
réalisé une interface avec le système OASIS 
du CNET qui réalise de telles preuves. Sur la 
version UNIX, nous sommes en train de con- 
cevoir et d’implanter un démonstrateur utili- 
sant la même approche, mais plus facilement 
modifiable et manipulant les preuves 
comme des objets. 


Des études théoriques 
sur les spécifications 
formelles 

Des études théoriques sont poursuivies dans 
notre équipe sur des sujets liés aux spécifica- 
tions formelles. On peut les grouper en 
quatre thèmes : la programmation fonction- 
nelle avec opérateurs de second ordre, la 
génération de spécifications à l’aide d’algo- 
rithmes de complétion, la résolution d’équa- 
tions et de “diséquations”, les applications 
de la théorie des institutions. 

© LA PROGRAMMATION FONCTIONNELLE : 


Dans un premier temps, nous avons étudié 
le langage de programmation fonctionnel FP 


(de J. Backus) et l'algèbre des programmes 
dérivée de ce langage. Les résultats de cette 
approche nous paraissent insuffisants car ils 
ignorent la notion de type. Les travaux que 
nous avons entrepris conduisent à une nou- 
velle conception d’un langage fonctionnel 
fortement typé. Celui-ci comprend : (1) la 
définition des types abstraits; (2) la défini- 
tion d'opérateurs de second ordre qui génè- 
rent les fonctions “inductives” sur ces types; 
(3) les règles d’inférence associées aux opé- 
rateurs de second ordre pour prouver des 
propriétés des programmes ; (4) des règles de 
transformation donnant des règles d’équiva- 
lence des programmes, c’est-à-dire une 
algèbre des programmes, 


e SYNTHÈSE DE SPÉCIFICATIONS ET DE 
PROGRAMMES , Les activités de notre 
groupe en synthèse de programme consis- 
tent à explorer l’analogie qui existe entre 
preuves et programmes. L'idée générale est 
qu'un programme peut être extrait de la 
preuve de sa spécification exprimée dans 
une logique adéquate. A cet égard, le langage 
LPG fournit un environnement qui offre au 
moins deux possibilités intéressantes : 

- appliquer le paradigme “preuve = pro- 
gramme” dans le cadre des spécifications 
algébriques, outil de preuve étant la pro- 
cédure de complétion de Knuth-Bendix, 

- exploiter la notion de généricité, une des 
caractéristiques fondamentales de LPG, 
pour poser correctement le problème de 
la synthèse au “bon niveau” d’abstrac- 
tion. 

Plus précisément les recherches actuelles 
sont regroupées autour de deux thèmes : 
(1) l'influence du choix des constructeurs sur 
la conception et l’efficacité des fonctions 
écrites sur des types abstraits, et les transfor- 
mations automatiques entre plusieurs de ces 
choix, (2) la synthèse des fonctions spéci- 
fiées par clauses de Horn : à partir d’une des- 
cription d’un opérateur par clauses de Horn, 
le système produit une spécification éven- 
tuellement conditionnelle de cet opérateur. 


e ÉQUATIONS ET DISÉQUATIONS : Les tra- 
vaux portent sur la résolution d'équations 
(=) et de diséquation (>) dans les algèbres de 
termes, les variables étant soit existentielle- 
ment, soit universellement quantifiées. Cela 
contient en particulier la théorie de Punifica- 
tion et généralise les résultats de Colme- 
rauer pour Prolog 2. Un formalisme et une 
sémantique des problèmes équationnels ont 
été décrits (collaboration avec P. Lescanne 
du CRIN) et il est montré que tout système 
peut se ramener à un système en forme nor- 
male. Un tel système est soit vide, soit est 
simplifié au maximum (plus de diséquations 
si possible), ne contient plus de paramètre, et 
admet toujours au moins une solution. Les 
résultats sont valables dans la théorie vide, 
ainsi que dans certaines classes de théories 
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équationnelles. Les applications sont nom- 
breuses : on peut citer le problème de la com- 
plétude suffisante dans le cas des spécifica- 
tions algébriques et celui de la réductibilité 
inductive dans le cas de preuves par induc- 
tion. De même, la transformation de spécifi- 
cations avec équations entre constructeurs 
en spécifications “order-sorted” sans équa- 
tions entre constructeurs est possible. Une 
autre application est celle de la négation en 
programmation logique où les diséquations 
servent à résoudre des problèmes de com- 
pléments qui vont autoriser à traiter des buts 
négatifs quelconques alors qu’on ne savait 
traiter que des buts négatifs clos (SLDNF 
résolution). 


e THÉORIE DES INSTITUTIONS : La théorie 
des institutions a été développée par Burstall 
et Goguen pour rendre compte des relations 
entre les formalismes logiques et les classes 
de modèles de ces formalismes. La logique 
du premier ordre est une institution, de 
même que la logique équationnelle ou la 
logique des clauses de Horn. Les liens entre 
des logiques “comparables” sont décrits à 
l'aide de “morphismes d'institutions”. Nous 
avons appliqué cette théorie pour com- 
prendre un mécanisme d’évaluation “dyna- 
mique” implanté dans un programme de cal- 
cul formel. Ce programme est destiné à faire 
des calculs dans des structures comme des 
corps, à l’aide de méthodes applicables à des 
structures plus faibles comme les anneaux. 
La possibilité de continuer ou non un calcul 
est automatiquement discutée par le sys- 
tème, et le contexte d’exécution est changé 
en fonction de cette discussion. 


Actions dans le cadre 
ESPRIT 


Participation au projet FOR-ME-TOO (Pro- 
ject ESPRIT n. 283) : “Formalisms - Methods 
- Tools: sofware development based on and 
supporting the concept of reusability ofcom- 
ponents” en 1987. En collaboration avec la 
division RTT d'INFIGENIE et en sous-trai- 
tance de SYSECA, nous avons défini un 
ensemble de primitives de structuration de 
composants algébriques. Cet ensemble a 
servi à la réalisation de la spécification algé- 
brique d’un gestionnaire de fenêtres pour le 
logiciel d’un écran haute résolution. Ces pri- 
mitives peuvent être considérées comme 
une extension du projet LPG dans le sens 
d’une programmation par composants. Elles 
fournissent des opérations de structuration 
horizontale et verticale. 


Participation au projet REPLAY (Project 
ESPRIT n. 1651 [1598]) : “replay et evaluation 
ofsofiware development plans using higher- 
order metasystems” et collaboration avec 
CISI Ingénierie, le CERT-DERI, l’université 
catholique de Louvain, le CRI (Danemark), 


la société Alpha (Grèce) et E2S (Belgique), 
Nous étudions les techniques “bottom-up” 
d'élaboration et de réutilisation de plans de 
développement de logiciels, ces plans étant 
considérés au niveau macroscopique 
comme des assemblages de composants, Le 
langage d’expérimentation est LPG, et nous 
recherchons à maîtriser les effets des modifi- 
cations d’un composant dans un système 
complexe où ce composant n’est qu’une par- 
tie. Les liens entre les composants peuvent 
être hiérarchiques (importation), d’instan- 
ciation, de représentation, etc. La suite de 
notre programme de travail est consacrée au 
développement de programmes algorithmi- 
ques à partir de spécifications, et à l’utilisa- 
tion d’un formalisme de méta-niveau pour 
décrire les opérations sur les composants, 


Perspectives futures 


L'atelier d'analyse de spécifications cons- 
truit autour de LPG sur stations SUN sera 


complété par des outils fondamentaux, 


comme le démonstrateur de théorèmes, et 
d’autres outils seront améliorés, en particu- 
lier le résolveur d’expressions logiques. Le 
langage LPG sera modifié pour prendre en 
compte la programmation et la spécification 
par composants. Il est prévu également des 
extensions vers la programmation algorith- 
mique (ADA) et développement des pro- 
grammes, 

Sur les parties théoriques, on envisage la 
poursuite des études sur les systèmes de réé- 
criture et les applications de la résolution 
d'équations et de diséquations, en collabora- 
tion avec les autres équipes du PRC travail- 
lant sur ce thème. Les recherches sur 
l'analyse des spécifications et la synthèse de 
fonctions seront approfondies, ainsi que les 
travaux sur les applications de {a théorie des 
institutions. 

Un certain nombre de résultats pourront 
faire l’objet d’implantations expérimentales 
dans l'atelier d'analyse de spécifications 
construit autour de LPG. Ce sont essentielle- 
ment la synthèse de fonctions par la mé- 
thode de complétion et la programmation 
fonctionnelle par opérateurs de second 
ordre. 

L'objectif fixé au terme de ce programme de 
travail est de mettre à la disposition des utili- 
sateurs, d’une part un seul formalisme qui 
englobe des logiques différentes, et d’autre 
part une palette d’outils adaptés à ces logi- 
ques ou fournissant des possibilités diverses 
d’expérimentation sur les spécifications (par 
exemple : évaluation, prototypage, vérifica- 
tions, génération de programmes, syn- 
thèse...). 


Contacts 
internationaux 
et industriels 


Collaboration avec l’université catholique 
de Louvain-La-Neuve (Belgique) pour la 
réalisation de l'atelier de spécification LPG 
sur SUN, Depuis 1987, cette collaboration est 
subventionnée par le CNRS et le CGRI. 


Contacts avec SYSECA et SIEMENS et réali- 
sation d’une étude de cas de spécification 
algébrique dans le cadre du projet ESPRIT 
FOR-ME-TOO : “Formalisms - Methods - 
Tools: software development based on and 
supporting the concept ofreusability ofcom- 
ponents” (1987). 

Participation au projet ESPRIT REPLAY : 
“Replay and evaluation of software develop- 
ment plans using higher-order metasys- 
tems” et collaboration avec CISI Ingénierie, 
le CERT-DERI, Puniversité catholique de 
Louvain et le CRI (Danemark) de 1988 à 1990. 
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bases de données 

interface homme-machine 
logique temporelle 

preuve de théorèmes 
prolog 

réécriture 

représentation des types 
spécifications algébriques 
spécifications formelles 
spécifications par types abstraits 
système de commutation 
systèmes distribués 

temps réel 

types abstraits algébriques 
validation de spécifications 






Objectifs scientifiques 


La division CLC du Centre Paris À travaille 
dans le domaine de la commutation et en 
particulier, elle participe à la définition des 
cahiers des charges des systèmes de commu- 
tation développés par les industriels à partir 
de ces cahiers des charges. 

Une part importante de la réalisation de ces 
systèmes consiste en développement de 
logiciels. Le logiciel d’un autocommutateur 
représente couramment un volume de plu- 
sieurs centaines de milliers de lignes de pro- 
gramme. 


Les coûts de développement et de mainte- 
nance de ces logiciels atteignent de telles 
proportions qu’il devient urgent de conce- 
voir des chaînes de production de logiciels 
plus sûres, donc plus automatisées ou plus 
assistées. Les spécifications sont actuelle- 
ment écrites en langue naturelle et souffrent 
de tous les défauts inhérents à ce type de 
représentation : ambiguïtés, incohérences, 
omissions. 

Il a donc paru nécessaire d’étudier des possi- 
bilités de représentation plus formelle de ces 
spécifications afin de pouvoir effectuer un 
certain nombre de contrôles de cohérence 
sur celles-ci, mais aussi de s'appuyer sur ces 
spécifications pour les étapes ultérieures de 
la réalisation des logiciels : conception, pro- 
grammation, mise au point, recette. 


L'objectif des études est donc de définir des 
formalismes de spécification adaptés aux 
domaines qui nous intéressent, et également 
les méthodes à mettre en œuvre pourutiliser 
ces formalismes avec un maximum d’effica- 
cité et les outils permettant d’appliquer ces 
méthodes avec sécurité et confort. Afin de 
valider notre approche, il est nécessaire de 
faire la preuve que l’application de tels for- 
malismes est viable sur des exemples signifi- 
catifs de notre domaine. Ce domaine re- 
couvre en fait quelques sous-domaines que 
l’on retrouve dans de nombreux systèmes 
informatiques : processus temps réel”, ges- 
tion de données, dialogue homme-machine. 


Etat actuel 
Les études faites ont abouti à la réalisation 
d’un certain nombre d’outils : 


e OASIS : outil de manipulation de types abs- 
traits, 

e interprète PROLOG, 

e GENTIANE : outil de vérification de formu- 
les de logique temporelle, 

e OVAL : outil de validation de spécifications 
de systèmes distribués écrites en langage 
LDS normalisé par le CCITT. 


En parallèle, des résultats théoriques ont été 
obtenus sur un certain nombre de points, 


Développements d'outils 
pour la mampulation 
de spécifications formelles 





parmi lesquels on peut mentionner : 


* relations entre les techniques de réécriture 
(Knuth-Bendix) et les techniques de résolu- 
tion, 

e relations entre logique temporelle et auto- 
mates, 


e techniques de résolution appliquées à la 
logique temporelle. 


LE SYSTÈME OASIS 

OASIS est un système de manipulation de 
types abstraits basé sur la notion de spécifica- 
tion algébrique. OASIS permet de traiter 
deux types d'objets : les types qui sont des 
spécifications proprement dites et les repré- 
sentations qui sont des implémentations 
d’objets à partir d’autres objets. 
Initialement développé sur un microproces- 
seur EXORCISER 6800 de Motorola, dans une 
version marseillaise de PROLOG, il a été 
transporté sur MULTICS pour des raisons de 
performance, ce qui a nécessité la réécriture 
de l'interprète PROLOG. 

Les principales fonctions d’OASIS sont : 

« la saisie interactive de types et de représen- 
tations, 


la compilation de types et de représenta- 
tions, 


e le contrôle de type, 


e l'évaluation symbolique des expressions 
de types ou de représentations, à l’aide d’un 
algorithme de réécriture, 


e la preuve de théorèmes sur un type ou une 
représentation, par réécriture, induction, ou 
traitement par cas, 


e la preuve de conformité d’une représenta- 
tion d’un type par rapport à sa spécification, 
e la vérification et la terminaison du système 
d'équations (algorithme de KNUTH-BEN- 
DIX). 

Mentionnons en particulier les facilités sui- 
vantes : 


einterface utilisateur très ergonomique 
grâce à l'introduction d’un système de multi- 
fenêtrage permettant l'utilisation de menus 
et d’une souris pour les désignations. Cette 
facilité est disponible sur la version SM90/ 
UNIX d’OASIS, 

© prouveur de théorèmes sophistiqué : en 
particulier, la cohérence des systèmes d’as- 
sertions générés lors d’un raisonnement par 
cas est vérifiée automatiquement, et de plus 
ces systèmes sont simplifiés au maximum. 
L'idée de base utilisée est l'application de 
lalgorithme de Knuth-Bendix aux asser- 
tions, considérées comme des équations 
sans variables. 

Enfin, une thèse est en cours sur la construc- 
tion de programmes à partir de spécifications 
formelles par types abstraits algébriques. Un 
langage intermédiaire permettant une des- 








Responsable scientifique 
Gérard Barberye 


cription abstraite d’algorithme a été défini, et 
les outils associés aux différentes étapes de 
passage d’une spécification à un programme 
sont en cours de définition. 


LE CHOIX DE PROLOG 

Pour réaliser un outil tel qu'OASIS, faisant 
appel aux techniques de manipulation sym- 
bolique et de réécriture, il nous a paru impor- 
tant de prendre un langage adapté. Notre 
choix s’est alors porté sur PROLOG. La pre- 
mière réalisation d'OASIS avait été faite sur 
un microprocesseur 6800, à l’aide d’une ver- 
sion de PROLOG développée par le GIA de 
Puniversité de Marseille-Luminy, mais des 
problèmes de performances nous ont con- 
duits à redévelopper un interprète PROLOG 
en PASCAL (pour des raisons de portabilité) 
sur un gros calculateur. 


Une première version de PROLOG/CNET 
était disponible en novembre 1981 sur MUL- 
TICS, et la dernière version développée parle 
CNET Paris À date de juin 1985. 


Les caractéristiques originales de cette ver- 
sion sont : 


e l'introduction de la notion de modularité, 


0 la possibilité de manipuler diverses formes 
du programme : texte source, forme objet 
{postfixée), image mémoire, 


9 la possibilité de manipuler un programme 
où une partie de programme en tant qu’objet 
PROLOG (terme), 


e l'accès au niveau PASCAL à une interface 
permettant à l’utilisateur de configurer sa 
version et de créer ses propres prédicats éva- 
luables, 


Divers utilitaires ont été développés autour 
de cette version : éditeur structurel, outil de 
trace, outil d'analyse statique et également 
en liaison avec OASIS, une interface bitmap 
(multifenêtrage, désignation par menus et 
souris) utilisant le serveur d’affichage 
APOTRE développé dans le cadre du projet 
CONCERTO. ‘ 

L'équipe a également étudié et réalisé une 
carte coprocesseur PROLOG pour la SM90, 
qui donne un gain d’environ 4 en temps 
d’exécution, la version de PROLOG associée 
restant parfaitement compatible avec la ver- 
sion standard PASCAL. 


UN OUTIL DE SPÉCIFICATION : GEN- 
TIANE 

L'outil GENTIANE permet de spécifier des 
systèmes de processus parallèles, et de prou- 
ver des propriétés dynamiques sur ces systè- 
mes, en utilisant comme formalisme la logi- 
que temporelle; et comme technique de 
preuve, l’extension du principe de résolution 
à cette logique {travaux de Fariñas Del 
Cerro). 


Organisme 

IONET - Centre Paris À - Division CLC 
{France TELECOM) 

38-40, rue du Général-Leclerc 
NB lssy-les-Moulineaux 

@ (1) 45294765 


Cet outil réalise les fonctions suivantes : 


e saisie interactive de spécifications ; la syn- 
taxe des propriétés temporelles et la saisie de 
ces propriétés ont été conçues pour être pro- 
ches de celles d'OASIS, 

eintroduction d’opérateurs plus évolués 
permettant une spécification plus lisible, 


e mise sous forme normale de chaque pro- 
priété avec détection d’une incohérence ou 
d’une tautologie, 

e preuve de propriétés sur la spécification par 
une technique de résolution, celle-ci pou- 
vant être contrôlée par l'utilisateur, 


Cet outil a été étendu de façon à pouvoir 
manipuler des formules de logique tempo- 
relle comprenant des opérateurs portant sur 
le passé et sur le futur. 


UN OUTIL DE VALIDATION : OVAL 
L'outil OVAL permet d'effectuer un certain 
nombre de validations sur des spécifications 
de systèmes de processus parallèles décrites 
dans le langage LDS,. 


Il faut signaler que le CNET a lancé des 
actions importantes en validation de logiciel 
en collaboration avec des industriels des 
télécommunications, ce qui peut être l'occa- 
sion. de transférer le savoir-faire de l’équipe 
vers le monde industriel. 

L'équipe participe également, dans le cadre 
de la phase principale du programme euro- 
péen RACE, au projet SPECS concernant les 
environnements de spécification pour les 
systèmes de communication et ayant pour 
échéance fin 1992. 


Réalisations 
logicielles disponibles 


Quatre logiciels sont actuellement disponi- 
bles : PROLOG, OASIS, GENTIANE et OVAL. 
L’interprète PROLOG/CNET est disponible 
sur MULTICS et il peut être mis gratuitement 
à disposition pour les besoins de la recherche 
et de l’enseignement publics. Il a déjà été dis- 
tribué à un certain nombre de centres : MUL- 
TICS INRIA à Rocquencourt et à Sophia- 
Antipolis, CICB, CICG, CICT,CICRP, CITI, 
Ecole des Ponts et Chaussées. 

Cet interprète a fait l’objet, en décembre 
1983, d’un contrat de licence avec la société 
CRIL en vue de son industrialisation et de sa 
commercialisation sous le nom de PRO- 
LOG/P. I est actuellement disponible sur 
une dizaine de types de machines de puis- 
sances diverses. L'équipe collabore avec la 
société CRIL pour définir les extensions qui 
sont faites à cet interprète. Il faut de plus 
noter qu’un compilateur est actuellementen 
cours de réalisation. 


Participants 
Ana-Rosa Cavalli 
Pierre Combes 
Georges Denis 
Véronique Lefort 
Max Michel 

Etienne Paul 
Mohamed Abdellaziz 


OASIS est actuellement disponible sur MUL.- 
ICS, sur VAX/VMS, sur SM90/SMX(MPX) et 
sur SUN. GENTIANE est disponible sur MUL.- 
TICS. IL peuvent être mis gratuitement à dis- 
position pour les besoins de la recherche et 
de l’enseignement publics, H est nécessaire 
de disposer de PROLOG/P pour pouvoir 
implanter ces outils. OASIS a été distribué au 
CILG, aux PTT Suisses, à l’ENST Brest et à 
Puniversité de Clermont-Ferrand. 


OVAL est actuellement disponible sur SM90/ 
SMX et sur SUN. Il nécessite de disposer de 
l'infrastructure CONCERTO et de PRO- 
LOG/P. 


Contacts hors PRC 
et contacts 
internatiomaux 


Contacts liés à des contrats DGT/DAIX ou 
CNET 

o LCR Corbeville : langage L, 

e Laboratoire de Marcoussis : langage 
PLUSS 

e IMAG/LIFIA : langage LPG 

o Ecole des Mines de Sophia : Esterel 
Contacts liés à des fournitures d'outils 

e Société CRIL : licence PROLOG/P. 
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SPRAC MOTS CLES 

atelier de génie logiciel 

bases de données projet 
CONCERTO (atelier de génie logiciel) 
environnements de programmation 
F1 (système d’information) 
génération de compilateurs 
langage de développement 

logique des prédicats 

méthodes de conception 

preuve de programme 

preuves de spécifications 
représentation des types 
réutilisation des programmes 
réutilisation des spécifications 
schémas conceptuels de systèmes d’information 
spécifications algébriques 
spécifications par types abstraits 
stratégies de preuve 

transformation de programmes 
transformation des spécifications 
types abstraits algébriques 
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UN OBJECTIF : PLUSIEURS PROJETS 
L'objectif général de l’équipe est d'étudier et 
d'assister par des outils informatiques les 
méthodes formelles de Conception de Pro- 
grammes Assistée par Ordinateur (1). Cet 
objectif général a conduit l’équipe à pour- 
suivre ses recherches à travers plusieurs pro- 
jets, tous dans la même lignée, Chronologi- 
quement, SPRAC de 1979 à 1984, TOOLUSE 
de 1984 à 1989, et en enfin REPLAY, son pro- 
jet compagnon débuté en 1986. 


Le projet SPRAC 


SPRAC [2j est un Système de Programmation 
par Réutilisation Assistée de Connaissances. 
Ï1 permet la spécification formelle de fonc- 
tions et de types abstraits dans le but de pro- 
duire et de valider des composants logiciels. 
SPRAC est principalement concerné par le 
développement de programmes classiques 
écrits en langages impératifs tel PASCAL. 


LES CARACTÉRISTIQUES 

SPRAC est basé sur les principes suivants : 

© la possibilité de décrire les objers du logiciel 
àtrois niveaux distincts, correspondant à des 
définitions de plus en plus proches de Pim- 
plémentation, 


e la présence d’une base de données projet 
(BDP) qui se comporte comme un espace de 
travail permanent ou temporaire. Le modèle 
de la BDP est relationnel. De ce fait, il sup- 
porte une description statique et dynamique 
des objets et de leurs interactions qui peut 
être facilement remise en cause pour être 
adaptée à de nouveaux types d'objets et de 
développements, 


e l’existence d’un ensemble d’outils fournis- 
sant une assistance active au développe- 
ment. Cette assistance s’appuie sur des tech- 
niques basées sur l'approche transforma- 
tionnelle. 


Ces trois caractéristiques sont prises en 
compte au travers du modèle de développe- 
ment et de son exploitation par les outils cor- 
respondants. Plus précisément, le dévelop- 
pement de logiciel est organisé d’une 
manière descendante à l’aide de trois forma- 
lismes différents : 


e au plus haut niveau, le langage LF, basé sur 
une logique typée des prédicats du premier 
ordre sert à spécifier des fonctions, des types 
abstraits et des représentations de types. Tous 
ces objets sont génériques, 

e au niveau intermédiaire, LA est un langage 
applicatif utilisé pour décrire des afgorith- 
mes, 

e enfin, au troisième niveau, LM considéré 
comme un langage de programmation dans 
lequel sont décrits les modules opérationnels. 


Conception de programmes 
assistée par ordinateur 





Il a été décidé d'introduire trois niveaux de 
langages afin d’isoler au mieux les problè- 
mes qui se posent lors du développement de 
logiciels, et qui sont en général traités simul- 
tanément dans un seul et même langage. 
Brièvement rappelés, ces problèmes sont : 


e Quelles sont les abstractions utilisées pour 
résoudre un certain problème ? Avec LF, les 
représentations de données (les structures 
concrètes) et le contrôle ne sont pas expri- 
més, ce qui permet de ne s’intéresser qu’au 
QUOI de la solution cherchée ! 


© Quel est le flot de contrôle ? 
LA, langage algorithmique abstrait, introduit 
les structures classiques des langages appli- 
catifs et donc permet d’exprimer le COM- 
MENT de la solution retenue, 


e Assumant les deux points précédents, 
quelles sont les meilleures structures de don- 
nées ? 

Les liens entre les types abstraits et Les types 
concrets sont supportés par la BDP elle- 
même, 

e Comment utiliser au mieux la mémoire du 
calculateur ? 

C’est au niveau du langage de la programma- 
tion que sont résolus les aspects gestion de la 
mémoire, partage de la mémoire, etc. 

LF et LA ont été conçus et implémentés pour 
faciliter Les étapes de spécification rapide et 
de description d’algorithmes. Comme LF et 
LA sont interprétables, leur utilisation per- 
met d’obtenir très rapidement des maquet- 
tes et des prototypes. L'utilisation de LM 
conduit à la réalisation du produit final. 


L'ENVIRONNEMENT 

L'environnement construit intègre les édi- 
teurs syntaxiques associés à LF et LA, les 
compilateurs correspondants, et principale- 
ment le gestionnaire de la Base de Données 
Projet qui constitue ainsi le noyau de SPRAC. 
En particulier, la BDP permet la définition et 
la gestion des liens statiques et dynamiques 
entre les objets décrits à des niveaux diffé- 
rents. Ces liens sont établis suivant deux 
dimensions : 


© DIMENSION SPATIALE 

Les objets sont liés par des relations telles 
que utilise, réalise, représente, implémente, 
instancie... Tous les objets et leurs liens 
appartiennent à une entité appelée VERSION 
qui correspond à une vue instantanée du 
projet. 

e DIMENSION TEMPORELLE 

Dans le but de garder une trace effective du 
développement d’un logiciel, la généalogie 
est préservée dans une entité appelée HISTO- 
RIQUE qui est en fait Parbre des VERSIONS. 


QUELQUES RÉALISATIONS 


Parmi les réalisations effectives autour de 
SPRAC, trois principaux résultats doivent 
être mentionnés : 
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© L'ASSISTANCE À LA PRODUCTION DE COM- 
PILATEURS [3] 

Les travaux menés ont abordé ce problème 
sous Pangle de l’obtention de compilateurs à 
partir de la définition de la sémantique déno- 
tationnelle des langages de programmation, 
En d’autres termes, comment obtenir une 
définition plus concrète (sémantique pour 
une machine à pile, à registres, etc.) et com- 
ment utiliser ce processus de concrétisation 
comme processus de génération ? La miseen 
évidence de règles de transformation entre 
une sémantique source et une sémantique 
cible permet d'obtenir des compilateurs vali- 
des par construction, 


o L'ASSISTANCE À LA TRANSFORMATION 
AUTOMATISÉE DE SPÉCIFICATIONS 

La BDP constitue un modèle du développe- 
ment de logiciel, dans lequel des états et des 
transitions entre états ont été formellemnent 
identifiés. Une plus grande assistance aux 
utilisateurs est apportée par des outils réali- 
sant certaines des transitions possibles. En 
particulier, (4) présente la transformation LF 
vers LA par synthèse automatique, et (5) 
donne un algorithme sous-optimal du pas- 
sage automatique de LA vers LM. 


e LE SYSTÈME D'INFORMATION F1 [10] 

Le formalisme F1 a été conçu pour per- 
mettre la description de schéma conceptuel 
de systèmes d'informations. C’est aussi un 
environnement complet qui permet la créa- 
tion et la manipulation de bases de données 
dans un formalisme uniforme. Ce dernier 
est basé sur : 


- une extension du modèle entité-relation 
permettant la prise en compte de la hiérar- 
chie des types, 

- une logique typée du ler ordre favorisant 
l'expression aisée de la recherche d’infor- 
mations et de contraintes d’intégrité à 
satisfaire. 


Fletson environnement PENELOPE consti- 
tuent un moyen efficace de prototypage 
d’environnements de logiciels, tant sur le 
plan des concepts qu’il permet d’appréhen- 
der que sur le plan des aspects purement 
machines. A titre de validation, SPRAC a été 
entièrement réécrit avec F1, avec une effica- 
cité certaine. 


Le projet TOOLUSE 


Le projet TOOLUSE est né de la volonté d’in- 
clure dans un environnement tel que SPRAC 
des langages et des outils de support de 
méthodes de développement. En effet, le 
modèle de développement supporté par la 
BDP de SPRAC étant relationnel, il est pos- 
sible d'exprimer des contraintes d’intégrité 
entre les objets d’une version. Cependant, 
ces dernières ne permettent que l’expression 
de ce qui doit être satisfait à posteriori, etnon 
ce qui doit être satisfait à priori, En d’autres 


Organisme 

ONERA-CERT 

Département d'Etudes et de Recherches 
en Informatique 

2, avenue E.-Belin 

BP. 4025 - 31055 Toulouse Cedex 

& 4155711 

Fax : 61557172, Télex 521596 ONECERT 


termes, la notion de méthodes (guides pour 
Putilisateur) ne peut être commodément 
mise en oeuvre à l’aide de méfaprogrammes. 
TOOLUSE (6) vise donc à fournir les moyens 
d’une assistance active pour la conception, 
implémentation, et l’évolution de logiciels. 
L'hypothèse de base est qu’une telle assis- 
tance doit être obtenue par la description du 
développement d’une manière formelle qui 
pourra donc être elle-même manipulée. Il 
est bien évident que la formalisation des 
développements passe par Les étapes suivan- 
tes : 


e étude et compréhension des méthodes de 
développement (7), 

e formalisation du processus de développe- 
ment (8), 

e définition et réalisation d’un langage de 
développement (9), 


+ réalisation de l’environnement support. 


Dans sa version actuelle, DEVA (le langage 
de développement) permet de spécifier des 
développement simples, rejoués à partir des 
exemples classiques. Un prototype de l’envi- 
ronnement est en cours d’achèvement, 





Le projet REPLAY 


REPLAY est le projet compagnon de TOO- 
LUSE, Son rôle principal est de mesurer Pim- 
pact des mécanismes et outils de manipula- 
tion de développement de logiciels dans un 
contexte de réutilisation de logiciels. I1 est 
donc complémentaire de TOOLUSE où l’ac- 
cent est mis sur les aspects expression des 
développements. Dans le but de promouvoir 
la réutilisation et les aspects évolutifs des 
développements déjà effectués, REPLAY 
concentre ses études sur : 


ela composition de plans de développe- 
ment, où interviennent à la fois les aspects 
réutilisation descendante et assemblage 
ascendant, 

* le contrôle permanent des propriétés afin 
de montrer que les contraintes opérationnel- 
les spécifiées dans le cahier des charges du 
logiciel à produire sont satisfaites (ou non). 


Les projets ESPRIT 


L'équipe CPAO du Département d'Etudes et 
de Recherches en Informatique de CERT 
n'étant pas subventionnée, elle doit recher- 
cher ses ressources financières auprès de 
divers contractants, Parti ceux-ci, la Com- 
munauté Européenne a une place de choix 
depuis 1984, En effet, le financement de la 
continuation du projet SPRAC est assuré par 
Ja CEE avec les projets TOOLUSE et REPLAY. 
Le passage d’une entité nationale à une 
entité européenne a fortement influencé à la 
fois Le contenu des recherches et la façon de 
travailler. 


DE } 
TN ou fo 
Participants 
J. Cazin 
M. Lemoine 
P. Michel 
V. Royer 
J.-L. Durieux 
P. Maurice 
N. Boulaya 
F Vivares 


La constitution de deux consortiurns res- 
ponsables respectivement de TOOLUSE et 
de REPLAY a conduit à établir des liens privi- 
légiés avec les laboratoires et industriels sui- 
vants : 
e pour TOOLUSE 
- en Irlande, le Trinity College à Dublin 
(TCD) (Prof, K. Ryan) et la société Gene- 
rics (H.J. Kugler) 
-en Belgique, l’université catholique de 
Louvain (UCL - Unité d’informatique) 
(prof. M. Sintzoff) 
-en Allemagne, le laboratoire GMD à 
Karlsruhe (Prof. S. Jahnichen) et la société 
Biomatic à Freiburg (G. Koch) 
-enfin, en France, la CISI-Enginierie à 
Toulouse (H. Horgen) 
epour REPLAY, CiSi-Enginierie et UCL 
(Prof. E. Milgrom) sont des partenaires com- 
muns, avec en plus : 
- en Grèce, la société ALPHA-SAI à Athè- 
nes (M. Gazoulidis) 
- au Danemark, la société CRI A/S à Copen- 
hague (J. Guldberg) 
- en Belgique, la société Expert Software 
Systems à Gand (M. Huybrechts). 


L'impact des relations privilégiées avec des 
laboratoires et des industriels étrangers est 
important, tant sur les plans purement tech- 
niques (échanges et transferts de technolo- 
gies) que sur les plans personnels (adapta- 
tion à de nouvelles mentalités, vision plus 
européenne du travail, échanges de person- 
nes). Les retombées positives du pro- 
gramme ESPRIT sont déjà très perceptibles, 


Autres contacts 
internationaux 
et industriels 


Pour autant, les projets ESPRIT ne nous font 
pas perdre les liens forts qui existent avec 
d’autres équipes ou industriels. En particu- 
lier : 

e l'INRIA à Sophia-Antipolis avec le projet 
GIPE (G. Kahn), 

e l’université de Grenoble avec les projets 
LPG (D. Bert) et ADELE (J. Estublier), 

9 JR. Abrial avec le démonstrateur de théo- 
rèmes B, 

+ le CNET avec le projet CONCERTO 

e etc. 
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Patrick Greussay, Patrick Salle 


“Langages et Outils 

pour l’Intelligence 

Artificielle” - 

Architeciures de 
machines-langages 

Ce pôle réunit actuellement toutes les 

grandes équipes françaises universitai- 

res et industrielles de renommée internationale quitravaillent, 
d'une part, sur les langages LISP, PROLOG et leurs dérivés, les 
langages d'acteurs et les langages à objets, d'autre part, sur 


l'architecture de machines dédiées à ces langages. 


C'est un pôle très actif et très productif qui voit apparaître de 
nouveaux projets menés par de jeunes équipes. Des produits 
sont commercialisés comme Lelisp, Prolog-Il, l'éditeur Winnie 
et bientôt le coprocesseur Mali. Ils font partie d'un ensemble 
très important de logiciels qui pour beaucoup ont dépassé le 


stade du prototype. 


Les liens du pôle avec l'industrie sont nombreux. Certaines 
équipes sont membres de laboratoires industriels renommés, 
Laboratoire de Marcoussis, Centre Scientifique IBM. D'autres 
sont à l'origine de la création de sociétés qui commercialisent 
leurs produits. Toutes ont des relations industrielles importan- 
tes qui permettent à ce pôle d'être actuellement présent dans 
quatre projets ESPRIT. Enfin deux équipes participent aux 
efforts de normalisation en étant membres de groupes : ISO, 
AFNOR et EULISP. 


Du point de vue des thèmes, LISP est 
toujours l'objet d'études fondamenta- 
les : normalisation, sémantique et 
d'amélioration des techniques d'inter- 
prétation et de compilation, De nou- 
veaux interprètes portables ont été dé- 
veloppés : COMMON-LISP, MétaVlisp, 
SCHEME, PLASMA. 








On peut noter également la permanence des recherches sur 
PROLOG avec la production d'interprètes et de compilateurs. 
Les études théoriques ont permis la définition du langage Pro- 
log-3 qui introduit la notion de contrainte sur les clauses de 
Horn. Le problème crucial de la récupération mémoire a 
trouvé des solutions logicielles et matérielles. Une architecture 
multiprocesseur pour une exécution parallèle de PROLOG est 
à l'étude. 


La communauté travaillant sur les langages à objets s'est for- 
tement développée. Le modèle défini dans ObjVlisp unifie les 
notions de classe et de métadasse et dlarifie les concepts utili- 
sés. Le rapprochement entre la notion d'objet et la program- 
mation logique semble un thème prometteur avec les projets 
Eloise, Ciel et Glance. Le lien avec la simulation est également 


à l'étude dans plusieurs équipes. 


La programmation parallèle fait partie des nouveaux enjeux 
avec pour cible les réseaux de sations et les multiprocesseurs, 
C'est un thème transversal que l'on 
retrouve dans les langages d'acteurs 
AL/1 et ABCL, les langages à objets 
LORE et objPive, et la programmation 
logique. C'est aussi l'étude de la pro- 
grammation des architectures parallè- 
les synchrones et plus récemment celle 


de l'approche connexioniste. 
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De nouvelles 
architectures 


Le projet COALA s’insère dans le cadre des 
calculateurs de la cinquième génération. 
L'objectif de ces calculateurs est de suppor- 
ter efficacement le traitement symbolique 
en utilisant différentes techniques liées à la 
représentation des données et aux outils de 
contrôle, en particulier le parallélisme. Plus 
spécifiquement, l'étude a pour but de mettre 
en œuvre et de supporter le parallélisme 
inhérent au langage PROLOG, sans l’inter- 
vention du programmeur. Elle couvre trois 
aspects : la définition d’un modèle d’inter- 
prétation répartie pour le langage PROLOG, 
la spécification des mécanismes d'accès aux 
données et des outils de contrôle de l'archi- 
tecture multiprocesseur et l’interconnexion 
des différents processeurs élémentaires. 


Prolog 
et le parallélisme 


LE MODÈLE D'INTERPRÉTATION 
RÉPARTIE 

Le modèle d'interprétation répartie utilise le 
concept d'acteur et s'appuie sur le graphe de 
connexion ET/OU de R. Kowalski. Îlexploite 
le parallélisme-OU dans la résolution et un 
parallélisme-ET/OU lié à un processus d’uni- 
fication entre environnements. 


Le graphe de connexion ET/OU est produit 
par une précompilation du texte source. 
Dans ce graphe, deux littéraux unifiables et 
de signe opposé sont reliés par un arc. Un 
arc, étiqueté par les liaisons des variables tra- 
duisant le résultat de l’unification des deux 
littéraux, exprime un résolvant potentiel. 


Les différents résolvants sont construits et 
résolus en parallèle. Une étape de résolution 
consiste à sélectionner un arc et à construire 
le résolvant associé à partir de l’environne- 
ment étiquette de l'arc. Le parallélisme-OU 
est obtenu en sélectionnant en parallèle les 
arcs issus d’un même littéral et le parallé- 
lisme-ET en unifiant en parallèle l’'environ- 
nement de l'arc choisi avec les environne- 
ments des arcs du résolvant, 


Les unifications parallèles sur les arcs sont 
prépondérantes : elles induisent un parallé- 
lisme-ET/OU qui différencie notre modèle 
de ceux qui exploitent exclusivement le 
parallélisme-OU. Ce parallélisme-ET/OU 
entraîne une diminution de l'espace de 
recherche grâce à la détection anticipée de 
l'échec de certains littéraux qui deviennent 
non liés au graphe. 


LA STRUCTURE MULTIPROCESSEUR 

Chaque processeur élémentaire possède 
une partie du graphe. Globalement, la 
mémoire peut être assimilée à un ensemble 
de mémoires locales; le dialogue entre les 
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processeurs étant assuré par des messages. 
Topologiquement, Parchitecture proposée 
est composée de plusieurs processeurs élé- 
mentaires banalisés et interconnectés au 
réseau par une unité de communication qui 
assure le routage des messages. Chaque pro- 
cesseur ne dialogue qu'avec un nombre 
limité de voisins. 


Simulation du modèle 


Un système complet de simulation de la 
structure multiprocesseur et du modèle a été 
réalisé. Il se compose de deux parties distinc- 
tes : un simulateur fonctionnel écrit en PAS- 
CAL et un simulateur système écrit en 
T-PROLOG. 


Le simulateur fonctionnel, à partir du texte 
source PROLOG, construit le graphe de con- 
nexion correspondant, distribue le graphe à 
la structure multiprocesseur, puis exécute la 
question posée par l'utilisateur en simulant 
le comportement de l'interprète. 

Afin de mesurer les performances de l’archi- 
tecture, un deuxième simulateur, plus 
orienté système, fut nécessaire. Ce simula- 
teur accepte en entrée latopologie du réseau 
d’interconnexion, la vitesse des canaux de 
communication et intègre les temps d’exé- 
cution des opérations élémentaires de 
l'interprète, obtenus à partir du simulateur 
fonctionnel. Il fournit en sortie différentes 


… statistiques, en particulier le temps d’exécu- 


tion du programme et la charge des diffé- 
rents processeurs élémentaires. 


Ce système complet de simulation a permis 
de valider différents points spécifiques à l’ar- 
chitecture multiprocesseur COALA, comme 
par exemple le nombre de processeurs, la 
topologie du réseau d’interconnexion, la 
définition du processeur élémentaire et le 
domaine d'application de la machine. Les 
conditions de simulation reflètent presque 
exactement le comportement de linter- 
prète. Les applications simulées sont de 
taille raisonnable ; différentes organisations 
de machine ont été étudiées : point à point, 
grille, cube... 


Les résultats de simulation ont montré 
qu’un gain substantiel est toujours constaté 
lorsque le nombre de processeurs augmente. 
De meilleurs résultats ont été obtenus pour 
les programmes PROLOG manipulant un 
grand nombre d’assertions. En pratique, il 
est possible d'envisager une topologie d’une 
centaine de processeurs ou plus. Ce nombre, 
raisonnable, rend la réalisation viable con- 
trairement à d’autres approches présentant 
un nombre exorbitant de processeurs. 


Concernant le réseau d’interconnexion, 
l’hypercube semble avoir le profil recherché. 
Ses performances sont intermédiaires entre 
la topologie point à point et la topologie grille 
et sa bonne régularité fait de fui un bon can- 
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didat pour une éventuelle maquette, La 
charge des processeurs élémentaires est cor- 
rectement répartie et ce, de façon naturelle, 
Ainsi, aucun mécanisme de contrôle de flux 
n’est nécessaire, 


La simulation a déterminé les unités fonc- 
tionnelles du processeur élémentaire. Initia- 
lement composé de deux unités, une pour 
Punification, l’autre pour la résolution, le 
processeur élémentaire est maintenant orga- 
nisé autour d’une seule unité de calcul, Ce 
choix a été validé par différentes mesures 
dynamiques montrant la disproportion des 
taux d'occupation des deux unités, quel que 
soit le nombre de processeurs élémentaires, 
Ainsi, la faisabilité d’un prototype a été 
démontrée avec un processeur élémentaire 
simple, banalisé et de faible coût. 


Extensions du modèle 
de base 


LE PARALLÉLISME-ET 

La première extension du modèle concerne 
la détection dynamique de sous-résolvants 
indépendants. 11 s’ensuit une forme de paral- 
lélisme-ET dans la résolution, en parfaite 
harmonie avec le parallélisme-ET/OU du 
graphe de connexion. 


L'indépendance des littéraux d’un résolvant 
repose sur la connaissance des occurrences 
des variables du résolvant. Cette connais- 
sance, mémorisée dans une table appelée 
table de dépendance, permet à un arc choisi 
par la résolution de construire dynamique- 
ment la table du prochain résolvant, L’utili- 
sation des tables de dépendance limite les 
unifications entre environnements du 
graphe et forme des groupes disjoints de lit- 
téraux lorsqu'ils existent, 


Le modèle s’est avéré suffisamment souple, 
facilement modifiable. De nouveaux messa- 
ges ont pu être ajoutés à la version initiale, 
sans perte d’homogénéité pour l’ensemble, 
Cette nouvelle version optimise jusqu’à 60% 
le nombre d’arcs et de messages. Elle ne 
nécessite aucun algorithme complexe d’or- 
donnancement des littéraux, de retour en 
arrière ou de jointure des solutions partiel 
les, Le modèle devient localement hiérar- 
chisé et les solutions sont obtenues par pro- 
duit cartésien des solutions partielles qui 
remontent dans le graphe. 


Les premières simulations montrent que ce 
modèle est surtout exploitable pour des pro- 
grammes déductifs-récursifs, déterministes 
Ou pratiquement déterministes, Ce résultat 
est encourageant, car, pour cette classe de 
programmes, seul le parallélisme-ET peut 
conduire à des performances acceptables. 
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LES APPLICATIONS PROLOG-BD 
La deuxième extension du modèle résulte 
des bonnes performances constatées pour 
les programmes PROLOG manipulant beau- 
coup d’assertions, Ces résultats sont à l’ori- 
gine d’une nouvelle version, actuellement 
en cours de développement et spécifique aux 
applications PROLOG-BD. 


La présence de nombreuses assertions dans 
un programme PROLOG pose le problème 
de lexplosion combinatoire du nombre de 
messages de résolution et d’unification, à 
cause du parallélisme-OU, 


Il est relativement facile de modifier le 
modèle initial afin de regrouper tous les 
messages en provenance d’un arc et à desti- 
nation de plusieurs arcs appartenant à un 
même processeur, H suffit de représenter 
tous les arcs d’une même partition sur le 
même processeur par un seul arc, qualifié 
d’arc virtuel, qui contiendra les environne- 
ments des assertions de cette partition. 


La liste des arcs de résolution ne sera plus 
constituée que des adresses des arcs virtuels, 
ce qui diminuera sa taille et, par voie de con- 
séquence, le nombre de messages émis. Ce 
nombre est maintenant fonction du nombre 
de processeurs de la structure multiproces- 
seur, mais en aucun cas de la taille des parti- 
tions, contrairement au modèle initial. 


Les principaux avantages de cette méthode 
concernent donc le nombre de messages et 
le temps moyen de construction du futur 
résolvant. Un autre point positif réside dans 
Palgorithme d’unification lui-même puis- 
qu’il ne s'applique que sur des variables 
et/ou des constantes: les différentes asser- 
tions étant mémorisées dans une structure 
particulière appelée matrice de liaisons. 





Perspectives 


RÉALISATION D’UNE MAQUETTE 
Après une phase de simulation qu’il est 
nécessaire de poursuivre afin d'affiner les 
résultats, nous souhaitons réaliser une pre- 
mière maquette à base de transputers. 

Un premier travail d'optimisation de la ver- 
sion de base a été entrepris : les différentes 
structures de données de l'interprète ont été 
linéarisées et l’algorithme d'unification 
compilé, afin d'accroître les performances. 
Les premiers résultats de simulation, obte- 
nus par extrapolation des mesures de la ver- 
sion de base, laissent espérer un facteur 5 en 
faveur de la version optimisée. 


Parallèlement, nous travaillons sur a défini- 
tion et la réalisation d’un noyau OCCAM 
pour l'écriture d’applications réparties. Ce 
noyau doit faciliter le portage de l'interprète 
sur Parchitecture multitransputer. 
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LES PRÉDICATS ÉVALUABLES ET LE 
MÉTA-CONTROLE 

Sur le plan théorique, nos efforts actuels 
concernent l'introduction des prédicats éva- 
luables PROLOG dans ce contexte de résolu- 
tion parallèle, essentiellement les prédicats 
de contrôle (prédicat COUPE-CHOIX), les 
prédicats de manipulation dynamique de 
clauses (prédicats AJOUT et RÉTRAIT) et les 
prédicats de dialogue avec l'utilisateur (pré- 
dicats d’entrée/sortie de termes). Il est égale- 
ment envisagé d’introduire dans le modèle 
différents méta-prédicats pour guider et 
optimiser la résolution, 


Contacts 
internationaux 

Par l'intermédiaire d’Ivan Futo que nous 
avons accueilli dans notre équipe pour une 
période de six mois, nous maintenons des 
contacts très étroits avec l’Institut pour la 
Co-ordination des techniques d’Ordinateur 
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Irène Durand, qui a pris en charge le modèle 
d'interprétation répartie, termine actuelle- 
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sité de Maryland. Cette équipe travaille éga- 
lement sur les problèmes du parallélisme en 
PROLOG, 
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LANGAGES-OBJETS MOTS CLES 
algorithmes parallèles 

C++ (couche objet pour langage C) 
CLOS (Common Lisp Object System) 
Common Lisp (langage de programmation) 
génie logiciel 

intelligence artificielle 

interface homme-machine 

Loops 

méthodologie de programmation 
objets (systèmes) 

ObjVLisp (langage objet) 
programmation par acteurs 
programmation par objets 
prototypage 

représentation des connaissances 
SimTalk 

simulation 

SmallT'aik (système objet) 

types abstraits algébriques 
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État de l’art : 
les objets, thèmes 
et variations 


La programmation par objets est aujourd’hui 
une sorte de label revendiqué par des pro- 
ducteurs de logiciels très divers (intelligence 
artificielle, génie logiciel). Il en résulte une 
certaine confusion. Le but des travaux me- 
nés par l’équipe est d’abord d'étudier les 
techniques implémentatoires permettant de 
réaliser des systèmes objets pour en extraire 
les mécanismes de base et en déduire en- 
suite différentes méthodologies de program- 
mation. 


Le texte ci-dessous rend compte des résul- 
tats obtenus depuis 1986 et s'articule autour 
des principaux thèmes développés par la pro- 
grammation par objets : 

e résultats relatifs à l'étude des langages déri- 
vés de Smalltalk-80 utilisant une taxinomie 
de classes et concernant la définition de 
nouvelles architectures objets pour Lisp : 
ObjVlisp et CLOS (Common Lisp Object 
System). En particulier développement de ja 
technique des métaclasses comme outil 
d’auto-représentation des objets du langage 
et d’extensibilité de celui-ci, 

e dans la lignée de Simula, étude de la contri- 
bution des langages à objets au domaine de 
la simulation et réalisation de la plate-forme 
d’expérimentation SimTalk, 


e résultats relatifs à la contribution de la pro- 
grammation par objets à la description d’al- 
gorithmes parallèles et au développement de 
Îa programmation dite par acteurs, 


e étude de Smalltalk-80 comme modèle de 
réalisation d’interfaces de haut niveau (le 
MVC) et comme outil de prototypage rapide, 
e étude des mécanismes annexes (contrain- 
tes, métaclasses, hiérarchie des parties, héri- 
tage multiple, démons, valeurs actives) per- 
mettant aux langages à objets d’aborder les 
problèmes de représentation des connais- 
sances posés par l'intelligence artificielle, 

e enfin, étude de l'intégration de la program- 
mation par objets dans le monde des langa- 
ges impératifs statiquement typés et étude 
de C++ comme outil de réalisation de nou- 
veaux modèles de systèmes d'exploitation. 


Étude des langages 

à Objets à taxinomie 
de classes : le modèle 
ObiViisp 

Le travail de réflexion débuté par Jean- 
Pierre Briot sur les mécanismes d’instancia- 
tion et d’héritage dans sa thèse de 3° cycle 
puis repris par Pierre Cointe a abouti à un 
modèle unifié pour la sous-famille des langa- 


Pour une méthodologie 
de la programmation par objets 






ges à objets utilisant la classe comme sys- 
tème de taxinomie et comme modèle d’abs- 
traction. 


Ce modèle implémenté dans la dernière 
version d'ObjVlisp unifie les concepts de 
classe et de métaclasse : une métaclasse 
devient un objet à part entière, 1.e., instance 
d’une vraie classe définie explicitement. En 
tant que classe, une métaclasse hérite nor- 
malement de ses sur-classes. Cette nouvelle 
théorie des métaclasses est décrite dans trois 
papiers qui ont été présentés à l'ECAP86, à 
PIJCAr87 et à OOPSLA’87. Au niveau métho- 
dologique, l’équipe étudie maintenant les 
possibilités offertes par la programmation 
par métaclasses, plus particulièrement en ce 
qui concerne les possibilités de paramétrisa- 
tion des mécanismes d’héritage et d’instan- 
ciation dans le but de simuler de nouveaux 
systèmes objets. 


L'unification métaclasse/classe nous a éga- 
lement suggéré une nouvelle définition du 
concept de variable de classe : nous propo- 
sons que les variables de classe définissant 
les connaissances globales à l’ensemble des 
instances d’une même classe soient définies 
explicitement comme les variables d’ins- 
tance de la classe vue comme un objet. L'une 
des conséquences est la mise en évidence 
d’un nouveau schéma de représentation des 
connaissances utilisant le mécanisme de 
l'instanciation que nous pensons générali- 
sable (voir l'exemple des polygones du 
papier UCAI). On peut maintenant paramé- 
trer Les classes au niveau souhaité en n’utili- 
sant que le seul concept d’abstraction/ins- 
tanciation. 


Enfin, notons que le modèle ObjVlisp est 
actuellement en cours de discussion par le 
groupe d'experts Eu-Lisp. Dans ce groupe, 
Pierre Cointe travaille avec Christian Quein- 
nec à la définition d’un système de types 
extensibles, et non hiérarchisé, permettant 
le contrôle des entités allouées au niveau du 
bit et devant intégrer un système de classes à 
la ObjVlisp (voir le papier soumis à la Confé- 
rence Lisp 88). 


Contribution 
d'ObjVilisp à la 
réalisation d’un 
Metaobiect kernel” 
pour CLOS 


Les potentialités des architectures réflexives 
(extensibilité, transparence, auto-descrip- 
tion, introspection) donnent lieu à des 
recherches de plus en plus nombreuses dans 
les domaines de la programmation Lisp 
GLisp, MetaVlisp), de la programmation 
logique (FOL), des langages de frames 
GKRS) et maintenant de la programmation 
par objets (voir le livre consacré au workshop 
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sur “Meta-Level Architectures and Reflec- 
tions” organisé en octobre 87 à Alghero). 
Jouant pleinement son rôle de laboratoire 
d'étude et de simulation, le système 
ObjVlisp nous a conduit à aborder les techni- 
ques des architectures réflexives. Le point de 
départ est encore le mécanisme d’instancia- 
tion et le mécanisme de régression à l'infini 
induit par les deux postulats : 


e toute entité est un objet, 

° tout objet est instance d’une classe, donc 
elle-même un objet d’après le postulat précé- 
dent. 


Pour réaliser cette régression, une technique 
classique (du moins en Loops et Smalltalk) 
est de définir une boucle sur la racine du 
graphe d’instanciation, la racine se définis- 
sant comme sa propre instance. Contraire- 
ment aux autres systèmes objets, ObjVlisp 
donne la définition de la classe racine (Class) 
en ObjVlisp même. Cette solution demande 
la description du bootstrap et conduit à 
décrire précisément l’allocation et l’initia- 
lisation d’une instance-terminale, d’une 
classe et d’une métaclasse, 

La description de ce boot-strap permet d’ex- 
pliciter à l'utilisateur l'architecture du sys- 
tème des classes (le couple Class/Object), 
ensuite la technique de la programmation 
par métaclasses lui permet d'étendre celui-ci 
(voir le rapport de DEA de N. Graube). 


Ii se trouve que, parallèlement aux travaux 
sur ObjVlisp, le sous-comité CLOS en charge 
de spécifier le système objet pour ANSI- 
CommonLisp utilise lui aussi les architectu- 
res réflexives pour construire le “Metaobject 
kernel” de CLOS (voir le papier de Bobrow et 
Kiczales à IWOLES’88). 


Nicolas Graube a entrepris de transformer le 
modèle ObjVlisp et sa machine virtuelle 
pour montrer que la technique des métaclas- 
ses ObjVlisp permet d'aboutir en plusieurs 
étapes au Metaobject kernel de CLOS dont il 
constituerait donc un sous-ensemble. Ce 
travail est la première partie de sa thèse con- 
sacrée aux architectures réflexives pour les 
langages à objets. 

En parallèle, Pierre Cointe travaille sur un 
ObjVlisp “multi-bootstrappable” permettant 
d'intégrer les fonctionnalités de CLOS (les 
variables d’instances, les méthodes, les com- 
binaisons des méthodes et les fonctions 
génériques deviennent des objets décrits par 
des classes). Il partagera avec Danny Bobrow 
une session sur les objets en Lisp lors du 
workshop sur l’évolution de Lisp et sa stan- 
dardisation (voir le papier IWoLES). 





Langages à objets 
et simulation : SimTealle 


Les problèmes abordés au LIB par Jean Bezi- 
vin sont principalement ceux de utilisation 


Laboratoires 

LITP : Campus Jussieu, Tour 45-55 (bureau 209), 
4, place Jussieu, 75005 Paris 

Rank Xerox France : DRDBI, 12, place de l'iris, 
Cedex 38, 92071 Paris La Défense 

LAFORIA : Campus Jussieu, Tour 45-55, 

4, place Jussieu, 75005 Paris 

LIB : UBO-ENSTBr, 6, avenue V.-Le-Gorgeu, 
29287 Brest Cedex 


de différents paradigmes de programmation 
dans un contexte de simulation et porte prin- 
cipalement sur l’étude du paradigme objet 
dans certaines de ses relations avec le para- 
digme processus. 

Cette étude est réalisée en prenant comme 
champ d'investigation le domaine des langa- 
ges de simulation à événements discrets, 
Pour ceux-ci, une plate-forme d’expérimen- 
tation (SimTalk) a été construite au dessus 
de Smalltalk-80 dans laquelle plusieurs 
modèles de parallélisme, de synchronisation 
et de communications peuvent être utilisés 
et comparés, 

L'idée de base consiste à considérer un pro- 
cessus comme un objet doté d’un fil de con- 
trôle. Plusieurs modèles peuvent alors être 
étudiés. Dans le modèle client-serveur par 
exemple, en plus des processus ou objets 
actifs, il ÿ a lieu de considérer également des 
objets passifs ou serveurs, L'accès à ces 
objets passifs peut s’effectuer selon diffé- 
rents protocoles. Contrairement à des langa- 
ges comme Ada, CSP ou Occam qui ont 
réduit la dualité processus/moniteur à la 
notion de tâche et qui se servent de ce méca- 
nisme pour prendre en compte l’agrégation, 
le point de vue de l’étude consiste à tirer 
avantage des relations “tout/partie” disponi- 
bles dans un langage à objets pour cons- 
truire, de façon structurée, au-dessus d’un 
mécanisme primitif de concurrence (le fil de 
contrôle) et d’un mécanisme primitif de syn- 
chronisation (le verrou ou le sémaphore) des 
mécanismes évolués de structuration de sys- 
tème. 


La notion de contrainte (au sens de Thing- 
lab) n’est pas étrangère à ce travail dans la 
mesure où elle nous permet de prendre en 
compte des situations de groupes où plu- 
sieurs processus ont un comportement indé- 
pendant mais cependant lié (banc de pois- 
sons, escadrille d'avions, ete.). 


Pro or um ma cui © ma 
parallèle et langage 
acteurs : ABCL 


Jean-Pierre Briot, lors de son séjour de deux 
ans au Japon dans le laboratoire de Akinori 
Yonezawa, a pratiqué intensément la pro- 
grammation par acteurs (plus particulière- 
ment le système ABCL : Actor Based Con- 
current Language, voir sa présentation à 
OOPSLA’86). Cette pratique de spécification, 
d’implémentation et d’utilisation des langa- 
ges acteurs la conduit à une réflexion sur les 
modèles d’héritage dans le contexte des lan- 
gages à objets concurrents (voir le papier pré- 
senté à ECOOP’87). 

À la suite de ces expériences avec des langa- 
ges à objets concurrents (ABCL, mais égale- 
ment ObjPive, extension de ObjVlisp vers 
les processus de Bernard Serpette et Pierre 
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Cointe, et Formes, présentés dans le livre 
OOCP édité par À. Yonezawa et M. Tokoro), 
nous débutons maintenant la modélisation 
d’un langage à objets parallèle basé sur une 
série de couches dont l’assembleur est une 
implémentation du modèle des acteurs de 
G, Agha. Ce projet va bénéficier du travail de 
réflexion sur les architectures réflexives 
pour assurer la cohésion entre ces différents 
niveaux. 

L'équipe dispose déjà de prototypes écrits en 
Lisp etenvisage dès maintenant l’implémen- 
tation sur des multi-processeurs (réseau de 
stations de travail, puis hypercube et trans- 
puters), 


Langages à objets 
comme oui 

de prototypage : 
Small. 8 © 


L'enseignement du langage Smalltaik-80 
nous à conduit à étudier la technologie du 
MVC qui permet d’associer à un Modèle (en 
fait une hiérarchie de classes) une Vue (une 
hiérarchie de vues) et un Contrôleur (une 
hiérarchie de contrôleurs). Cette méthodo- 
logie rend compte des interfaces entre un 
objet informatique, ses représentations ex- 
ternes sur l’écran et ses interactions avec 
l'extérieur via les boutons d’une souris. 
Outre qu’elle permet de prototyper très rapi- 
dement des applications de haut niveau d’in- 
teractivité, son intérêt principal réside dans 
la description - en terme de hiérarchie de 
classes - des bibliothèques Smalltalk décri- 
vant les différentes sortes de vues et de con- 
trôleurs. 

En fait, Smalitalk-80 permet non seulement 
la description du langage mais aussi celle de 
son environnement que Putilisateur averti 
peut donc adapter à ses désirs. Par exemple : 
redéfinition des menus, modification du 
comportement des espaces de travail, défini- 
tion de nouveaux browsers (flâneurs) ou de 
nouveaux inspecteurs, Nous pensons donc 
que le MVC doit faire partie des méthodolo- 
gies du génie logiciel. 


Applications systèmes 
des langages à objets 
“à types abstraits” 


Philippe Gautron est membre du groupe 
SOR (Systèmes à Objets Répartis) de INRIA. 
Dans ce cadre, il développe sous la direction 
de Marc Shapiro un système à objets répartis 
(SOS) pour le projet Esprit SOMIW. Cette 
recherche utilise intensément le langage 
C++ et a donné lieu à la réalisation d’un édi- 
teur de liens dynamique permettant la mi- 
gration d’objets (voir le papier Usenix 87). 
Cet éditeur de liens autorise une communi- 
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“Two extensions fo C++" P. Gautron 

et M. Shapiro, Proceedings of the first 
C++ workshop USENIX, Santa Fe NM, 
USA, novembre 1987. 


“TimeLock: À Concurrent Simulation Technique 
and its Description in Smalltalk-80', 3. Bezivin, 
W5C’87 {Winter Simulation Conference), 

pp. 503-506, Atlanta GE, USA, décembre 1987, 


“Applying the MVC Scheme to Simulation 
Software’, J. Bezivin, International 
Conference on Modelling and 
Simulation, Karlsruhe, FRG, juillet 1987. 


“The fransparency property of TimeLock, 
a Concurrent Object-Oriented Simulation 
Technique’, 3. Bezivin, International 
Conference on Modelling and 
Simulation, FRG, Karlsruhe, juillet 1987. 


“Inheritance Mechanisms in Object-Oriented 
Concurrent Languages’, J.-P. Briot et 

À. Yonezawa [fIT), ECOOP’87 (European 
Conference On Object-Oriented 
Programming}, LNCS n° 267, Springer Verlag, 
éditeurs : J, Bezivin, P. Cointe, J.-M. Hullot 

et H, Lieberman, 1987. 


“The Formes System: À Musical Application 

of Object-Oriented Concurrent Programming", 
P. Cointe, J.-P. Briot et B.-P. Serpette, chapitre 
du livre intitulé : Gbjeet-Oriented 
Concurrent Programming, MIT Press, 
éditeurs : A. Yonezawa et M. Tokoro, 
Cambridge MA, USA, 1987. 


“Une présentation de Smalltalk-80 au travers 
de son environnement de Programmation, 


Pour une méthodologie de la programmation par objet 


cation inter-sites fiable qui devrait permettre 
d'utiliser SOS comme une plate-forme d’ex- 
périmentation d’un univers multimédia dis- 
tribué reposant sur l’approche objet. 


Étude des apports 
des langages objets 
à l’Intelligence 
Artificielle 


L'arrivée de Jean-François Perrot au LAFO- 
RIA a donné un poids plus grand aux recher- 
ches sur Putilisation des langages à objets en 
Intelligence Artificielle, 


“Il a notamment lancé un programme d’ex- 
périmentation en Loops, dans le cadre du 
grant Ranx Xerox France”, sur diversthèmes 
intéressant le Cemagref et le CEA. Le but est 
de se faire une opinion motivée sur l’utilité 
des structures plus complexes que les clas- 
ses/instances (démons, valeurs actives, rè- 
gles) qui fleurissent dans les langages desti- 
nés à l’IA, et sur les styles de programmation 
avec métaclasses et héritage multiple (tra- 
vaux de Thierry Fuhs). 

D'autre part, Robert Voyer a poursuivi ses 
travaux sur les structures d’objets dans les 
mécanismes d’inférence. Il a écrit un moteur 
en Smalltalk-80 et développe un système ori- 
ginal en cours d’expérimentation. 

Jacques Ferber développe le langage Me- 
ring-3, issu de ses précédents travaux et 
explore les architectures “multi-agents”, Sa 
thèse d’État sera l'aboutissement de cette 
recherche. 


Activités annexes 

de promotion 

de le programmation 
par objets 

En dehors de ces prerniers résultats scientifi- 
ques, le groupe a participé activement à l’or- 
ganisation de différentes manifestations 


consacrées au thème des objets. Nous re- 
tiendrons plus particulièrement : 


e Pécole d'été 86 de l’'AFCET à Montréal : la 
méthodologie objet illustrée au travers d’un 
cours sur Smalltalk-80 (J. Bezivin, P. Cointe 
et J.-F Perrot), 


e création de la première conférence euro- 
péenne sur la programmation par objets 
(ECOOP’87) organisée par P'AFCET à Paris en 
juin 87 et participation active à ECOOP’88 qui 
aura lieu en août à Oslo. Par ailleurs, on parle 
déjà de l’organisation d’une conférence 
jointe ECOOP/OOPSLA au Canada en 89... 

e animation de différents séminaires indus- 
triels (IGL, Orsys, Cognitech, Bull, Iriam, 
Completive, Elf...) consacrés soit à la pro- 
grammation par objets, soit au langage 


Smalltalk (80 et V). Pour ces animations, 
l'équipe a conçu - sous forme de transpa- 
rents - deux supports de cours qui corres- 
pondent à une formation en cinq jours, 


e participation aux activités de normalisa- 
tion du langage Lisp et du système objet 
associé : Pierre Cointe est membre des grou- 
pes AFNOR, EU-LISP et ISO etsuitlestravaux 
du sous-comité CLOS du groupe ANSI-LISP. 


Réalisations et 
logiciels disponibles 
ObjiVlisp 

Trois versions sont actuellement disponi- 
bles : en Le-Lisp 15.2 (Cointe), en Kyoto 
CommonLisp (Consel et Deutsch) et en 
InterLisp-D (Graube). Du point de vue de 
implémentation, Charles Consel et Alain 
Deutsch ont notablement accéléré l'accès 
aux méthodes et aux variables d’instances en 
réalisant un “tree-walker” et un cache local à 
chaque classe, Le tree-walker permet de 
compiler les chemins d'accès aux variables à 
l'instant de la définition d’une méthode, le 
cache permet de stocker l’adresse d’une 
méthode dans le graphe d’héritage après son 
premier appel. Nicolas Graube a réduit le 
nombre de primitives de la machine virtuelle 
en augmentant encore le caractère réflexif. Il 
a par ailleurs utilisé les métaclasses pour 
implémenter les valeurs actives de Loops en 
ObjVlisp. 


SimTalk 

Es disponible sur tout système Smalltalk- 
80. 

CLOS 

Le prototype de CLOS réalisé par Nicolas 
Graube est disponible sur la version Xerox 
de CommonLisp (machine 1186). 


Contacts 
Internationaux 


L'équipe travaille en collaboration étroite 
avec plusieurs équipes étrangères : 


Xerox PARC : Danny Bobrow et Gregor Kic- 
zales (CLOS). 

EuroPare : Tom Moran et Austin Henderson 
(interface : NoteCard, HyperCard). 
Tokyo-IT : Akinori Yonezawa (ABCL). 

MIX Media-Lab : Henry Lieberman (acteurs, 
multi-média). 

ParcPlace Systems : Adèle Goldberg, Glen 
Krasner et Peter Deutsch (Smalitalk-80). 
Université libre de Bruxelles (VUB) : Luc 
Steels et Pattie Maes (Computational Re- 
flection, KRS). 

Université de Pise et Delphi Sa : Giuseppe 
Attardi et Maria Simi (DCLOS, Omega). 
Université de Montréal : Jean Vaucher et Guy 
Lapalme (Smalitalk-80, Plasma). 

Université d’Oslo : Kristen Nygaard (Beta). 
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P. Cointe, Convention Informatique, 
pp. 155-167, tome B, Paris, avril 1987. 


“The OBJVLISP Model: Definition of a Uniform, 
Reflexive and Extensible Object-Oriented 
Language”, J.-P. Briot et P. Cointe, Advances 
in Artificial Intelligence-Il, North- 
Holland, éditeurs : B. Boulay, D, Hogg et 

L. Steels, Amsterdam, Pays-Bas, 1987. 


“Les langages à Objets : un Nouveau Siyle de 
Programmation", P. Cointe, La Recherche, 
vol, 17, n° 248, pp. 1564-1567, Paris, décembre 
1986. 


“Object-Oriented Concurrent Programming 

in ABCL/1% À. Yonezawo, J.-P. Briot et 

E. Shibayama, OOPSLA’86 (Object-Oriented 
Programming Systems Languages and 
Applications}, Portland OR, octobre 1986, ACM 
Sigplan Notices, vol, 21, n° 11, novembre 1986. 
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LORE MOTS CLES 

bases de données 

Eloise (couche pour la programmation logique) 
environnements de programmation 
intelligence artificielle 

Loops 

Lore (langage objet) 

paraltélisme et objets 
programmation déclarative 
programmation par objets 
programmation par règles 
simulation symbolique 

systèmes de contrôle 

systèmes experts 





“La programmation par objets; le langage 
Lore”, Lettre IA n°6, publication des 
Laboratoires de Marcoussis, Décembre 1986. 


“Lore : un langage objet relationnel et 
ensembliste”, Ch, Benoït, Y, Caseau, 

Ch. Pherivong, Actes des 3° Journées d'études 
sur les Langages Obiets, Paris, Janvier 1986. 


“Lore et la Programmation par Objets’, 
Ch. Benoit, J.-L. Giavitto, Rapport n° R.G.8.86, 
Greco de Programmation, Avril 1986. 


“Knowledge Representation and 
Communicotion Mechanisms in Lore’, 

Ch, Benoit, Y. Caseau, Ch. Pherivong, Proc. of 
ECA'86, Brighton, Juillet 1896. 


“The Lore Approach to Object-oriented 
Programming Paradigms’, Ch. Benoit, 

Y. Caseau, Ch. Pherivong, OOPSLA'86, Poster 
Session, Portland (Oregon), Septembre 1986. 


“An Object-oriented language: Lore', 
À Caseau, Proc. of HICSS'87, Kona, Hawaïi, 
Janvier 1987. 


“La machine LISE", P. Dixneuf, Rapport de DEA, 
Université Pierre et Marie Curie (Paris VI}, 


Juin 1987. 


“Lore 2.2 Guide Utilisateur’, Rapport 
technique. L..0, Laboratoires de Marcoussis, 
Août 1987. 


“Étude et réalisation d'un langage objet: Lore’, 


Y. Caseau, Thèse de l'Université de Paris-Sud 
{Orsay}, Novembre 1987. 







Boîte à Outils pour 


La programmation par objets constitue 
une méthode informatique extrêmement 
féconde de modélisation des objets du 
monde réel et de description de leursinter- 
actions, Elle est particulièrement bien 
adaptée à l’étude des systèmes pouvant 
être schématisés par un ensemble d’élé- 
ments ayant chacun leurs caractéristiques 
propres et interagissant par échange 
d'informations ou d’instructions. 


L'intérêt de cette approche pour la repré- 
sentation et la manipulation des connais- 
sances en intelligence artificielle a conduit 
les Laboratoires de Marcoussis à dévelop- 
per un langage nouveau dénommé Lore, 
constituant principal d’un environnement 
de programmation modulaire, 


Ce langage se caractérise par son haut 
degré d’abstraction, toutes les notions 
utilisées étant représentées sous forme 
d'objets, et par la puissance de son mode 
de communication. De plus, il intègre un 
système de gestion des exceptions offrant 
ainsi à l'utilisateur un environnement 
complet d'aide à la programmation. 


Le développement en cours d’un système 
d’inférences, appelé Eloïse, et d’un envi- 
ronnement graphique et interactif spéci- 
fique, permet dès aujourd’hui de faire de 
Lore un outil puissant bien adapté aux 
problèmes de : 

e simulation symbolique : fonctionnement 
d'équipements industriels ou de matériel 
de transport; 

e systèmes experts : surveillance de sys- 
tèmes complexes tels que les turboalter- 
nateurs, gestion de réseaux, aide à la main- 
tenance, problèmes d’ordonnancement 
d’ateliers flexibles, conception assistée par 
ordinateur, compréhension et reconnais- 
sance de la parole; 

o gestion de bases de données : assistance 
à Putilisation de catalogues ou de docu- 
mentations etc. 


Lore est actuellement disponible, au stade 
préindustriel, sur des postes de travail Sun. 
Il est utilisé comme logiciel de base pour 
des applications civiles ou militaires avec 
des filiales du groupe CGE. Diffusé auprès 
d'universités, il sert de support d’enseigne- 
ment et de recherche. Lore a déjà fait 
Pobjet de plusieurs présentations interna- 
tionales. 


Lore 
et le programmation 
par objets 


Lore propose un modèle homogène pour 
décrire des mécanismes de représentation 
des connaissances issues des langages à 
objets classiques et des langages de sché- 
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mas, mais également, un protocole de 
communication qui se place dans un con- 
texte différent d’un contexte purement 
séquentiel et applicatif, C’est ce modèle 
que nous présentons dans les paragraphes 
suivants. 


OBJETS, CLASSES ET PROPRIÉTÉS 

Lore est un langage à objets conçu pour la 
représentation des connaissances. Son ori- 
ginalité vient du fait qu’il repose sur un 
modèle puissant qui intègre les aspects de 
structuration propre aux langages à objets 
et les aspects relationnels propres aux lan- 


gages de représentation de connaissances 


classiques. I1 ne suffit pas que laxiome 
“tout est objet” soit un point de dogme, dé- 
finissant par sa seule existence la notion 
d'objet. Ce qui est important, c’est de dis- 
poser d’une définition bien définie: d’un 
objet, dont fautes les entités du langage 
soient des représentations. Un objet n’est 
plus seulement la donnée d’un ensemble 
de caractéristiques statiques, les attributs, 
et de caractéristiques procédurales, les 
méthodes. Toute'entité manipulée par le 
langage doit être un objet, décrit par le mê- 
me modèle. 


Pour ce faire, le modèle de Lore s’appuie 
sur les notions d'ensemble et de relation, 
Les ensembles sont le support des classes 
et les relations, celui des propriétés défi- 
nies sur ces classes, De cette façon, un lan- 
gage à objets est ainsi modélisé par la don- 
née d’une hiérarchie de classes (une classe 
= un ensemble), représentée par un rreillis 
d’inclusion, et par des propriétés discrètes et 
fonctionnelles, représentées par des rela- 
tions définies sur des produits cartésiens 
d'ensemble. 

Cette homogénéité dans les concepts et 
cette structuration dans la description des 
caractéristiques et des comportements des 
entités sont essentielles, d’une part à la lisi- 
bilité et à la modularité des programmes, 
d'autre part à l’extensibilité du système, 
Cette approche nous offre des fonctionna- 
lités originales comme la définition par 
sélection (regroupement d'objets vérifiant 
une ou plusieurs caractéristiques en un 
ensemble), ainsi qu’une méthodologie pour 
Ja résolution des conflits lors d’héritages. 


COMMUNICATION ET CONCURRENCE 
L’implémentation classique de la passa- 
tion de messages pour les langages à objets 
est l’appel fonctionnel ou procédural. La 
seule différence entre le fait d’invoquer 
une méthode et celui d’invoquer une fonc- 
tion est que le premier implique un algo- 
rithme pour retrouver le code de la métho- 
de tandis que le second a directement 
accès à l'adresse du corps de la fonction. 

Or, la communication par passation de 
messages entre différentes entités du lan- 
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gage traduit à la fois un transfert d’infor- 
mations et le déclenchement d’un traite- 
ment. 


Un bon moyen de sortir du modèle de 
communication par appel/retour de fonc- 
tion est d’offrir des primitives permettant 
à l'utilisateur de spécifier la façon dont 
l'évaluation d'un message doit intervenir. 
Les primitives de communication du lan- 
gage doivent permettre de répondre à trois 
questions : quand, où et comment déclen- 
cher l'évaluation d’un message par l’objet 
receveur, c’est-à-dire décider du contexte 
d’exécution pour l'évaluation du message, 
Autrement dit, les primitives de communi- 
cation du langage permettent à l'utilisateur 
de décrire la passation du contrôle de l’exé- 
cution entre différents objets et en particu- 
lier, Le rôle de chacun des deux partenaires 
d’une communication : l'émetteur et le 
receveur. 


L'envoi d’un message ne peut plus être 
confondu avec son évaluation, le receveur 
pouvant être un objet autonome auquel est 
associée une puissance de calcul traitant 
l'évaluation d’un autre message, On obtient 
alors un contexte d'exécution multiple où 
environnement objet est global et cer- 
tains messages peuvent s’exécuter en 
temps partagé. Tous les problèmes de con- 
flit d'accès et de partage de temps doivent 
être résolus par le système de messagerie. 
De plus, si le protocole de communication 
spécifié se place dans un contexte d'exécu- 
tion répartie, l’environnement peut ne 
plus être global et le système doit gérer le 
convoyage des messages qui dépend alors 
de la topologie de la répartition des objets 
sur les processeurs. à 


En conséquence, pour un langage à objets, 
spécifier des primitives de communica- 
tions qui ne se contentent plus de se subs- 
tituer à un appel fontionnel, implique de 
mettre en place un véritable protocole de 
communication, soutenu par un système 
de messagerie. Il faut donc ajouter un 
niveau au langage à objets et s'intéresser à 
l'adéquation de ce niveau avec la machine 
hôte, 


Le système de messagerie de Lore propose : 


UNE DICHOTOMIE ASK/ISEND : le rôle de 
l'émetteur est de déterminer le type de la 
communication qu'il désire faire : une 
requête (ask) ou une transmission (send). 
La primitive ask traduit une dépendance 
vis-à-vis d'un résultat. La primitive send 
traduit au contraire une indépendance to- 
tale vis-à-vis, non seulement d’un résultat, 
mais aussi de la bonne réception du messa- 
ge. L'objet qui émet ce message garde le 
contrôle et continue son traitement cou- 
rant. 


Organisme 

Laboratoires de Marcoussis 
Centre de Recherches de la C.GE. 
Route de Nozay 

91460 Marcoussis 


DIFFÉRENTES FAÇONS DE DONNER LÉ 
CONTRÔLE AU RECEVEUR : l’environne- 
ment d'exécution pour le traitement du 
message est-il créé pour l’occasion ou 
s’agit-il de l’environnement courant, c'est- 
à-dire celui du traitement effectué par l’ob- 
jet émetteur? D’autre part, lorsqu'il reçoit 
un message, un receveur est soit actif 
(au travail), soit inactif. S’il est inactif, il 
devient actif et effectue le traitement du 
message reçu. S'il est actif, plusieurs cas de 
figure sont possibles, Si le message a été 
envoyé de manière asynchrone, par exem- 
ple par la poste, il est stocké dans la boîte 
‘aux lettres associée au receveur et sera exa- 
miné plus tard. Si le message est envoyé de 
manière synchrone, par exemple par télé- 
phone, le receveur a la possibilité de con- 
tinuer à travailler (laisser sonner le télé- 
phone), ce qui a pour effet de bloquer 
l'émetteur, ou bien de répondre, au risque 
de ne pouvoir effectuer son travail correc- 
tement. Lore définit donc une deuxième 
dichotomie entre les messages et distingué 
le mode immédiat (le message est traité 
dans le contexte courant) du mode bufferi- 
sé (un nouveau contexte d'exécution est 
créé). 
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L'environnement 

de programmation 

de Lore 

L'environnement de programmation de 
Lore est constitué d’une part d’un environ- 
nement graphique et interactif et d'autre 
part d’un environnement d’aide à la mise 
au point. 

Devant la multiplication des matériels et 
des logiciels disponibles pour la construc- 
tion d’interfaces interactives et graphi- 
ques, la nécessité s’est fait sentir de définir 
une base d’outils logiciels qui soient à la 
fois économiques, performants, d’une mi- 
se en œuvre simple et dont la portabilité 
soit envisageable sans trop de difficultés 
sur différents types de matériels. 
L'architecture logicielle de l’environne- 
ment graphique et interactif est composée 
de deux couches distinctes. La première 
couche, appelée EGB, définit un environ- 
nement graphique de base, Il s’agit d’une 
bibliothèque d’objets assurant la gestion 
de fenêtrage, de tracé graphique et des mo- 
yens de saisie interactive que sont la souris 
et le clavier. La deuxième couche est une 
librairie d’utilitaires graphiques. Ces utili- 


Enr 
UV DD 
ms ‘Tu 





“1060 jee 


on prants À 

















reel Dé 





Vonte de Vunttun on 1900 QU! 
Ho 


ferd 


























HÉEET VE DE 
PEN AR AM AL SUN AUNL AQU SP OCT HV De 

















LSUBSETS OF] SET 


SELECT. EG 
: st DEMUGGER coenson 
nu ora) [john 1sa pergon ago 10} 
| EXCEPLIQH-CLASS EJOHND 
IBÉAL=SET 
LA HASIMOI. ora> [bt11 


SET-OE PROPERTIES 


Lore efson environnement de programmation. 








Lors intoractar 


oraÿ Tpéraon 18n rang 
auperaot obf 
utth 
Cle a99 range Intagar) 
Gutt{-ratat{on frtonda rangs poruao)] 






re) (HUIT ica porvon age 9 friends John] 
BILLD 








] 
onu (CPERSOND) Loro Entoçactor Hems 
UNE: BILL 


voip 








GE 9 _—- s 
RIENDS: (CJ0H} pi 
BILLD 

NL ore) D dasctivate 10 














Fiven Input d 


INTELLIGENCE ARTIFICIELLE a 


L 


ET OUTILS POUR 





Î 
| 
| 
i 


u 
œ 


ARCHITECTURE DE MACHINES LANGAGES 





“An experimentation of Concurrent Lore with 
MTCL: comparison with ofher languages’, 

F. Carré, Tech. Report MADS TR-87.2, Esprit 
Project P440, Décembre 1987. 


“An Object-oriented Exception Handling 
System for an Object-oriented Language’, 
Ch. Dony, Tech. Report, Laboratoires de 
Marcoussis, Decembre 1987. 


“Construction of Lore : from the model to the 
language”, Y. Caseau, Tech, Report, 
Laboratoires de Marcoussis, Décembre 1987. 


“Eloïse: À Rule Oriented Programming 
Environment on Lore’, P. Dixneuf, À. Meller, 
P, Porcheron. Tech, Report, Laboratoires de 
Marcoussis, Décembre 1987. 

"Eloïse : le système inférentiel du langage à 
objets Lore”, P. Dixneuf, À. Meller, 

P. Porcheron. Rapport Tech,, Laboratoires 
de Marcoussis, Décembre 1987. 


Boîte à outils pour le développement d’applications 


d'intelligence artificielle 


taires sont développés entièrement à partir 
des objets disponibles dans la couche EGB. 


La librairie est composée d’un ensemble 
de modules distincts regroupant chacun 
un certain nombre de fonctions logique- 
ment liées selon le concept de boîte à ou- 
tils, comme par exemple l’afficheur de gra- 
phes acycliques. Le rôle de cette librairie 
est de fournir un maximum d’outils prédé- 
finis afin, d’une part, d’alléger la tâche de 
programmation des interfaces graphiques 
et, d’autre part, de permettre une certaine 
uniformisation de la représentation et du 
style d'interaction. 


L'élément principal de l’environnement 
d’aide à la mise au point est un système de 
gestion d’exceptions. Utilisable de façon 
standardisée par les modules du système et 
par les programmes utilisateurs, il offre 
une représentation en termes d’objets des 
exceptions et des Aandlers. Les handlers 
peuvent être associés à toute expression 
exécutable aussi bien qu'aux classes d’ob- 
jets. Au sein d’un handler, il est possible de 
provoquer la reprise du calcul interrompu 
ou la terminaison de l'exécution de l’ex- 
pression à laquelle le handler est attaché. 
Les outils de base de l’environnement de 
mise au point, destinés à la détection, la 
localisation et la correction des erreurs, i.e. 
des exceptions non traitées, utilisent avec 
profit ce système de gestion des excep- 
tions. En particulier, outil d'examen dela 
pile d'exécution est écrit en Lore et utilise 
les possibilités du modèle avec reprise. 


Eloïse : le système 
inférentiel de Lore 


Malgré ses nombreux avantages, un langa- 
ge à objets pur est peu adapté à la descrip- 
tion de comportements (heuristiques), de 
quantifications, de négations ou disjonc- 
tions de faits (au contraire d’un formalis- 
me de règles de productions). D’une façon. 
générale, un mécanisme d’inférences per- 
met par contre une programmation décla- 
rative des comportements des objets. 


Le rôle d’un tel module intégré à un langa- 
ge à objet, peut s’interpréter comme étant 
d'augmenter la capacité de réponse du sys- 
tème ainsi constitué face à des assertions 
ou des requêtes -- le mécanisme d’héritage 
se charge déjà d’une partie de cette fonc- 
tion. En effet, le système peut ainsi trouver 
les implications d’une nouvelle assertion 
(donnée par l’utilisateur ou engendrée par 
le moteur) grâce à l'exploitation de règles 
en chaînage avant. Et pour certaines requê- 
tes, il peut exploiter des règles en chaînage 
arrière pour obtenir des réponses qui ne 
sont pas disponibles dans la base de faits. Il 
peut donc par exemple répondre à des 
questions du type : 


Est-il vrai que? (chaînage arrière) 
Pourquoi est-il vrai que... ? (explication 
du chaînage arrière) 

Qu’arrivera-t-il à... ? (chafnage avant) 
Qu'’arrivera-t-il si..? (chaïnage avant 
hypothétique) 

Que devra faire l'opérateur pour que... ? 
{chaïnage avant + planification) 


Le système inférentiel Eloïse a été conçu 
dans lobjectif d'obtenir une intégration 
maximale avec le langage de programma- 
tion Lore afin d'offrir un outil homogène 
permettant de bénéficier, aussi bien des 
qualités des langages à objets, que des sys- 
tèmes traditionnels à règles de production. 
Cette intégration réside avant tout dans le 
fait que le système inférentiel ne suppose 
pas de modèle particulier de représenta- 
tion des connaissances et qu’il utilise donc 
directement la structure hiérarchique du 
monde des objets. La collaboration entre 
le langage à objets et le système inférentiel 
confère à l’outil Eloïse une puissance supé- 
rieure à des systèmes tels Art ou Kee, où ni 
la structuration objet du langage de repré- 
sentation externe, ni sa disponibilité en 
tant que langage de programmation à part 
entière ne sont respectées. Cette collabo- 
ration rend Bloïse beaucoup plus proche 
des systèmes comme Loops ou Fork, eux 
aussi intimement liés à un langage à objets, 
dont ils respectent la structuration. Cepen- 
dant, Eloïse possède un pouvoir d’expres- 
sion supérieur à celui de ces deux systèmes 
et permet également de bénéficier de tou- 
tes les spécificités de Lore par rapport aux 
langages à objets sur lesquels sont bâtis ces 
deux systèmes, 


Eloïse se caractérise par les éléments sui- 
vanis : 

e toutes les entités Eloïse sont des objets 
Lore et le système est intégralement écrit 
dans ce langage; 

e Eloïse utilise, pour vérifier la validité des 
prémisses des règles, les valeurs des attri- 
buts des objets du monde Lore; 

e Eloïse modifie, en fonction des consé- 
quences des conclusions des règles, les 
valeurs des attributs des objets du monde 
Lore. 


Le module de chaînage avant d’Eloïse 
repose sur un moteur d’inférences du pre- 
mier ordre autorisant non-monotonie et 
négations. Son langage de représentation 
permet l’écriture des règles sous forme 
déclarative, tout en conservant la puissan- 
ce d’expression du langage Lore. Il permet 
également la structuration des règles en 
expertises et amas d’expertises, Son ins- 
tanciation est assurée efficacement : seuls 
sont pris en compte, à chaque cycle, les 
changements intervenus dans la base de 
faits. Sa résolution de conflits est assurée 
soit par stratégies programmables, soit par 
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des méta-règles. 

Le module de mise au point actuel offre à 
l'utilisateur d’Eloïse un environnement 
graphique et interactif permettant entre 
autres l’analyse pas à pas du déroulement 
des sessions du système et l'inspection gra- 
phique des objets ou des relations entre les 
objets. 


Réalisations logicielles 
disponibles 


L'environnement de programmation Lore 
et le système inférentiel associé Eloïse 
sont des logiciels disponibles sur postes de 
travail Sun 3 et Common Lisp. La création 
d’un service de maintenance et d’aide à 
Putilisateur, ainsi qu’une documentation 
technique complète, permet aujourd’hui 
un développement régulier des applica- 
tions réalisées à partir de ces outils. 





Une application de simulation développée en 
collaboration avec Alsthom. 


Perspectives futures 


Les perspectives futures du projet “Boîte à 
Outils” s’articulent autour des axes sui- 
vants : (1) Développement de Lore et 
d’Eloïse, (2) Parallélisme et langages à ob- 
jets, (3) Explorer les apports respectifs des 
technologies des bases de données et de La 
programmation par objets, 


1LORE ET ELOÏSE 

Au-delà de l'enrichissement de l'environ- 
nement de programmation de Lore et l’ad- 
jonction de nouveaux modules à Eloïse 
(chaînage arrière, système de maintien de 
la cohérence), Pobjectif global est de défi- 
nir peu à peu une méthodologie de la pro- 
grammation par objets. 


2 PARALLÉLISME ET LANGAGE 

A OBJETS 

L'équipe est partie prenante au sein du 
projet Esprit P440 : Message Passing Archi- 
tectures and Description Systems. L’ob- 
jectif de notre participation est à terme de 
disposer d’un environnement d'exécution 
concurrent et réparti, intégré à un système 
de représentation des connaissances tels 
que Lore afin de supporter des applications 
du type : simulation, systèmes répartis, etc. 
L'élément principal de cet environnement 
est un Noyau Exécutif Concurrent compa- 
rable à un Operating System. 

En collaboration étroite avec notre parte- 
naire italien DELPHI, un modèle d’exécu- 
tion parallèle a été spécifié. Ï1 a été appli- 
qué à Lore par une implémentation avec 
MTCL, extension concurrente de Kyoto 
Common Lisp développée par Delphi. Ce 
modèle d’exécution permet d’envisager la 
coopération puis le parallélisme dans Les 
langages à objets, de façon nouvelle, L’en- 
semble des objets est considéré comme 
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une donnée manipulée par les différents 
modules d'évaluations de Lore, ceci 
contrairement au classique modèle des 
acteurs, ; 

3 BASES DE DONNÉES ET 
PROGRAMMATION DES OBJETS 

La représentation des connaissances est 
un domaine central dans la construction 
des systèmes experts. Un intérêt grandis- 
sant concerne l’intégration de la techno- 
logie des bases de données avec la techno- 
logie des systèmes à base de connaissances 
{programmation par objets, inférence et 
déduction, raisonnement non monotone, 
etc.). Les objectifs de cette intégration sont 
notamment l’utilisation de grands volu- 
mes de données dans les systèmes d’'IA et 
inversement la valorisation des bases de 
données existantes par des applications de 
type systèmes experts. Dans un premier 
temps, il s'agira de définir les apports spé- 
cifiques de Lore et d’Eloïse pour Pinterro- 
gation et la manipulation de base de don- 
nées relationnelles. 
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ARCHITECTURE 


MANENS MOTS CLES 


théorie des atgorithmes 

CENTAUR (sémantique dénotationnelle) 
ESTEREL (langage temps réel synchrone) 
génération de programmes 

intelligence artificielle 

langage de spécification 

MANENS (langage fonctionnel) 

OLGA (outil de compilation) 
progfammation fonctionnelle 
programmation relationnelle 

RagTime (projet) 

RAPTS 

réutilisation des programmes 

S3L (langage fonctionnel) 

SETL 

Syntax (méta-compilateur) 

temps réel 

théorie des algorithmes 

types abstraits algébriques 
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S3L est issu du langage MANENS, conçu par 
F. Le Berre et fondé sur la “théorie des Algo- 
rithmes” de L. Nolin. Dans cette théorie, 
tous les objets (fonctions et arguments), 
appelés algorithmes, sont de la même na- 
ture: ensembles d'un même domaine 
(TOUT) comportant les ensembles mathé- 
matiques et une classe de fonctions sur ces 
ensembles. Manens implante cette théorie. 
Tout objet du langage est donc à la fois 
ensemble et fonction. MANENS est un lan- 
gage ensembliste et fonctionnel. C’est le 
matériel de départ du travail du groupe. 


Une nouvelle version, implantée par J.-J. La- 
crampe, tendait à en souligner encore le 
caractère fonctionnel : 

eles constantes (ensembles mathémati- 
ques) deviennent des fonctions constantes 
qui sont leur propre résultat, 

o les ensembles du langage peuvent désor- 
mais contenir des fonctions. 


S3L est l'interprète noyau du langage résul- 
tant des réflexions du groupe MANENS. Le 
changement de nom tend à mettre l’accent 
sur le fait que les objets du langage, tout en 
conservant leur caractère fonctionnel, ne 
sont plus des ensembles, mais des “collec- 
tions”, n-uplets d'objets pour lesquels 
lordre est significatif, mais pas lPemboîte- 
ment. 


eLe O-uplet est la borne inférieure du 
domaine. 

e Les l-uplets représentent les scalaires des 
langages classiques. 

Les n-uplets (n > 1) dénotent le pluriel. 


La version actuelle est écrite en Le-lisp ver- 
sion 15.2. 


Les axes de travail du groupe sont les sui- 
vants : 


1. Dans une perspective de validation du lan- 
gage : écriture de la sémantique dénotation- 
nelle de S3L et implantation du langage à par- 
tir de celle-ci en utilisant CAML. 


2. Réalisation d’implantations plus perfor- 
mantes ou plus confortables. 


e Implantation en C “à la main”. La concep- 
tion de S3L autorise une programmation 
sans variable. Sans imposer ceci à l’utilisa- 
teur, cette possibilité peut être exploitée au 
niveau interne pour construire un interprète 
performant. 
e Implantation à partir de la sémantique 
dénotationnelle de S3L utilisant les outils de 
CENTAUR. 
e Implantation utilisant les grammaires attri- 
buées et comme outils SYNTAX et OLGA. 


3. Étude de l'extension de S3L aux objets 
infinis. Par construction, des objets infinis 
font partie du domaine de S3L. Ils ne sont pas 
pour l'instant gérés par l'interprète, Techni- 





Un interprète pour le langage 


quement leur prise en compte rend néces- 
saire l'introduction d’un concept d'équité 
dans l’évaluateur. Concrètement, le pro- 
blème posé est celui de l’utilité de tels objets 
ou plutôt celui de la définition de primitives 
“intéressantes”. 


4. Étude de l’intégration dans S3L des pro- 
grammations fonctionnelle et relationnelle. 
La construction théorique de S3L sous forme 
de domaine rend convergentes ces deux 
notions. Unification et résolution peuvent 
être abordées sous forme fonctionnelle. En 
liaison avec le traitement des objets infinis, 
S3L peut être étendu de façon à intégrer ces 
deux formes de programmation. 


5. Utilisation de S3L pour la construction 
d’un système de gestion de bases de don- 
nées, Fondé sur une approche ensembliste 
des bases de données relationnelles, il per- 
mettra de traiter de l'information disjonctive 
ou négative. 


Participation & 
un projet ESPRIT 2 


Le groupe MANENS est engagé dans la pré- 
paration du Projet Esprit RAGTIME (Reu- 
sable Components and Automated Genera- 
tion of Real-Time Implementations) à lini- 
tiative de THOMSON-CSF. 

RAGTIME se propose de construire un logi- 
ciel de haut niveau pour la spécification de 
systèmes comprenant du temps-réel et du 
parallélisme. Ses premiers objectifs sont : 

e assister le développement de prototypes de 
haut niveau, 

e permettre le passage des prototypes à des 
implantations efficaces et de bonne qualité. 
Pour atteindre ces objectifs, Ragtime envi- 
sage d'utiliser : 

eune machine transformationnelle basée 
sur CENTAUR, 

e un langage de spécification à large spectre 
s'appuyant sur SETL, 

e TYPOL pour formaliser la sémantique 
naturelle, 

os une théorie transformationnelle utilisant 
RAPTS, 

e ESTEREL pour la description formelle des 
systèmes temps-réel réactifs, 


La participation du groupe MANENS à ce 
projet se ferait dans les trois directions sui- 
vantes : 

e réflexion sur le langage de référence de 
Ragtime : SETL par comparaison avec S3L, 
© étude de la commodité et de l'efficacité des 
outils Ragtime pour l’implantation de S3Len 
comparaison avec les autres implantations 
prévues, 

eintégration des possibilités concurrentes 
de C-SETL dans les applications de S3L vers 
la programmation relationnelle et les bases 
de données. 
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Problématique 


L'équipe Méta travaille sur une nouvelle 
méthode d’implémentation des langages de 
programmation, appelée méta-récursivité, 
consistant à utiliser le langage à implémenter 
comme étant son propre méta-langage. 
Cette technique pose plusieurs problèmes 
intéressants, et procure de nombreux avan- 
tages aux systèmes de programmation ainsi 
réalisés : fiabilité due à l’absence dans Fim- 
plémentation d’objets étrangers au langage, 
clarté des concepts issue d’une définition 
rigoureuse de Poutil d’implémentation, 
accessibilité totale par l'utilisateur des com- 
posantes du système, portabilité facilitée par 
Pabsence de toutes considérations de bas 
niveau, pour ne citer que les traits les plus 
saillants. Les problèmes posés sont essen- 
tiellement le choix du bon sous-ensemble 
du langage spécifiant la machine virtuelle 
pour l'implémentation du langage complet, 
et les problèmes d’efficacité induits par le 
double niveau d’interprétation. 


Réalisations 


Après une longue réflexion théorique sur le 
premier point durant l’année 1985, la réalisa- 
tion de prototypes de tels systèmes a été 
effectuée en 1986, pour Lisp et les langages à 
Objets, sur différentes machines à base de 
68200, 6800, 8086 et 6809, L'année 1987 a per- 
mis d'améliorer les performances des pro- 
totypes, et d'obtenir des systèmes concur- 
rentiels par rapport à leurs homologues 
implémentés classiquement, grâce à des 
techniques originales d’interprétation, telles 
que Pexécution itérative de récursivités non- 
terminales, et lélimination d’invariant de 
boucle dans les fonctionnelles d’ordre supé- 
rieur. Aujourd’hui, l’équipe propose deux 
systèmes, Méta-Vlisp et Méta-Objets, sur 
trois machines, Sun 3, PC et nano-réseaux, 
avec leurs manuels d'utilisation complets. 


Perspectives 


Outre le portage sur d’autres machines, et 
Pamélioration des versions existantes, 
notamment au niveau de la communication 
avec les systèmes hôtes (Unix et MS-DOS), 
l’équipe compte à la fois montrer l’adapta- 
tion des systèmes à présent existants à diffé- 
rents problèmes de génie logiciel, et appli- 
quer la méthode à d’autres langages de 
programmation, afin d’obtenir leur machine 
virtuelle idéale, et des techniques d’interpré- 
tation spécifiques. En ce qui concerne le 
deuxième point, les études portent sur les 
langages utilisant lunification et la semi- 
unification d’ordre 2, En ce qui concerne le 
premier point, ils’agit d’une part de l'écriture 
de l’environnement de programmation (pas 
à pas réversible et compatible avec les inter- 
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prétations itératives, tutorial intégré, désas- 
semblage symbolique de la mémoire), et 
d’autre part la production automatique du 
compilateur à partir de l’évaluateur, par une 
étude théorique et pratique de l'évaluation 
partielle. 


Contacts industriels 


Le Centre National de Documentation 
Pédagogique (CNDP) a passé commande à 
Péquipe Méta de langages de programma- 
tion implémentés selon les techniques déve- 
loppées. Meta-Vlisp et Méta-Objets opéra- 
tionnels sur PC et Sun 3 eten version réduite 
sur MOS. 


i 
Î 
ï 
ï 
} 





Responsable scientifique 
Christian Queinnec 


SCHISP MOTS CLES 
intelligence artificielle 
sémantique des langages 

lisp (langage de programmation) 
normalisation des langages 
programmation par objets 
sémantique dénotationnelle 






Étude et réalisation 


Organisme 

LiT.P. Université de Paris VI 
4, place Jussieu 

75230 Paris Cedex 05 

& (1143259874 


Le projet SCHISP 


Lisp aura trente ans en 1988 et pourtant, sa 
normalisation via la très officielle Organisa- 
tion Internationale de Standardisation (ISO) 
n'a débuté qu’en fin 1986. Cette évolution 
n'est que la conséquence naturelle de l’en- 
gouement croissant que lui porte l’industrie 
relativement au marché naissant mais pro- 
metteur que constitue l’Intelligence Artifi- 
cielle. 

La standardisation n’est pas un processus 
novateur en ce sens qu’elle ne doit normali- 
ser que les pratiques existantes, Le cas parti- 
culier de Lisp constitue cependant un sujet 
de recherche complexe en raison : 

e de la richesse de la communauté Lisp : plus 
de deux cents dialectes ont vu le jour et une 
dizaine (non compatibles entre eux) domi- 
nent le terrain. Tout existe mais un choix de 
traits harmonieux reste à opérer, 

e La définition d’un ISO-Lisp ne peut être 
que le fruit d’un effort de formalisation qui 
n'a jamais été mené pour Lisp et qui, compte 
tenu de l’héritage mathématico-logique 
dont se réclament ses pratiquants, doit être 
d’un niveau supérieur aux normes actuelles 
(verbeuses et imprécises). 


Actualités 

et Perspectives 

Dans le droit fil de ces tendances, l'équipe 
“Sémantique et Prospective des Langages 
Applicatifs” du LITP s’est lancée dans le pro- 
jet SCHISP, projet d'étude et de réalisation 
d’un système IS0-Lisp de nouvelle généra- 
tion. Les points forts de ce nouveau dialecte 
seront : 

o une sémantique claire, 

oe une forte compilabilité, 

e la nette séparation des environnements de 
développement et d’exécution, 

e l'intégration de mécanismes pour la pro- 
grammation par objets, 


Outre sa participation à l'élaboration de 
ce nouveau dialecte qui sera proposé à 
PAFNOR, l’équipe en étudie plusieurs réali- 
sations. 

eLa première est une implantation en 
sémantique dénotationnelle qui servira de 
prototype de référence. Pour ce faire, sonten 
cours de développement des interprètes de 
sémantique dénotationnelle ainsi que des 
outils de mise au point (traceur, pisteur) et 
un interprète réversible (au sens de Lieber- 
man). 

Cette version de référence sert de labora- 
toire pour la mise à l'épreuve d’adjonctions 
(nouvelles formes spéciales) ou pour l'exa- 
men de variantes définitionnelles (macros, 
modules). 
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e La seconde est plus classique et vise la pro- 
duction d’un compilateur de qualité où sont 
plus particulièrement étudiés les points sui- 
vants : 

- compilation fonctionnelle de qualité, 

- typage fort optionnel et inférence de types, 
- dérécursivation avancée, 

- couche objet compilable, 

- génération de bibliothèque d’exécution 
minimales, 

- optimisation globale, 

- intégration avec UNIX/C. 


Par ailleurs, les besoins industriels d’au- 
jourd’hui tels qu’ils peuvent être pressentis 
ne sont pas seulement de disposer d’un stan- 
dard Lisp mathématiquement bien fondé, 
mais bien d’obtenir des compilateurs de 
haute qualité, conduisant à un code sûr, effi- 
cace et compact. La réunion des buts précé- 
dents est dans la droite ligne de la tradition 
française autour de Lisp. La réunion de tous 
ces traits est originale et devrait conduire à 
un intéressant prototype de compilateur. 


Relations 
internationales 


L'équipe participe aux travaux de normalisa- 
tion à l’échelon français à l’AFNOR, euro- 
péen dans le groupe EU-LISP et international 
à PISO. 

L'équipe a aussi organisé conjointement 
avec l'AFCET, l’AFNOR et l'INRIA les Pre- 
mières Journées Internationales sur Lisp, sa 
normalisation et son évolution (IWoLES”88). 
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PLASMA MOTS CLES 

ALOG (langage d'acteurs) 
architecture parallèle 
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environnements de programmation 
intelligence artificielle 

LiLA (machine virtuelle) 
machine abstraite/virtuelle 
parallélisme de contrôle 
parallélisme des données 
PLASMA++ (langage d'acteurs) 
programmation logique 
programmation par acteurs 
programmation par objets 
réseaux de machines 


Programmation par acteurs 


Le but du projet est la définition et Pimplé- 
mentation d’un système complet et portable 
de programmation par acteurs. La portabilité 
est favorisée par la définition et l’implémen- 
tation sur divers sites d’une machine vir- 
tuelle avec laquelle nous réalisons toutes les 
implémentations des diverses composantes 
du système. Depuis la première implémen- 
tation et les études sémantiques du langage 
PLASMA, nous avons développé ce système 
qui comporte : 

e une famille d’interprètes pour PLASMA et 
les langages d’acteurs ALOG, PLASMA++, 
ALI dont PLASMA est le noyau et qui intè- 
grent respectivement les programmations 
logique, à objets et concurrente. 

e un système de trace et de mise au point, 
e un compilateur du langage PLASMA, 

e une machine virtuelle support des implé- 
mentations. 


Les langages d’acteurs sont des langages 
apparentés aux langages applicatifs et issus 
de l'intelligence artificielle, 

Dans un langage d’acteurs, une application 
logicielle est conçue comme un ensemble 
d'acteurs qui échangent des données par 
messages. Le contrôle s'exprime au moyen 
de ce seul mécanisme de transmissions de 
messages. L'acteur est une entité de calcul 
autonome. Il possède une mémoire locale et 
des connaissances, les acteurs qu’il connaît, 
et il réalise, à la réception d’un message qui 
s'effectue par filtrage, un traitement qui peut 
consister en trois tâches : 

e création de nouveaux acteurs, 

e transmission de messages à des acteurs et 
éventuellement à lui-même, 

e modification éventuelle de son comporte- 
ment. 

Il en résulte deux sortes d’acteurs ayant un 
comportement distinct à l’égard des messa- 
ges qu’ils reçoivent : 

e les acteurs purs pour lesquels l’ordre d’arri- 
vée des messages n’influe pas sur les résul- 
tats: ils peuvent donc être librement reco- 
piés en instances traitant des messages de 
manière indépendante. 

e les autres qui peuvent changer de compor- 
tement à chaque événement (réception d’un 
message); ces acteurs n'existent qu’en une 
instance unique et traitent séquentiellement 
les messages qui leur sont envoyés. 


Dans ce modèle, tous les objets sont des 
acteurs, ce concept ne fait pas la distinction 
entre données et procédures. 


Les interprètes des langages séquentiels 
PLASMA, ALOG et PLASMA++ sont réalisés 
sur la machine virtuelle LILA (Langage 
d’Implémentation des Langages d’Acteurs) 
implémentée sur SUN, VAX, MAC INTOSH. 


Recherches actuelles 


L'apparition des machines à architecture 
parallèle n’a pas été accompagnée d’un déve- 
loppement comparable du logiciel pour utili- 
ser efficacement ces nouveaux matériels. Un 
des problèmes fondamentaux est de trouver 
un langage adéquat pour mêler calculs paral- 
lèles et séquentiels. 

Le modèle d'acteur a été développé afin de 
bâtir une théorie pour le calcul parallèle : si 
on peut associer à chaque acteur une puis- 
sance de calcul propre, l’ensemble des 
acteurs décrivant une application s’exécu- 
tera de manière concurrente. 

Si le problème à résoudre est décomposé en 
parties indépendantes, traitées en parallèle, 
dont les résultats sont ensuite combinés, on 
parle de parallélisme de contrôle. Mais on 
peut également répartir un ensemble de 
données et appliquer en parallèle la même 
fonction sur chaque élément de l’ensemble. 
11 s’agit alors d’un parallélisme de données. 
Le modèle d'acteur propose un moyen d’ex- 
pression uniforme de ces deux formes de 
parallélisme. 


Le langage AL 1 est un langage de program- 
mation parallèle implémentant le modèle 
d’acteur et dont PLASMA est la composante 
séquentielle. Son implémentation nécessite 
des travaux simultanés sur une nouvelle 
définition de machine virtuelle MVRI ainsi 
que des études sur un environnement de 
programmation distribué, 


LANGAGE AL 1 

Comme en PLASMA, l'acteur a son environ- 
nement propre, mais pour lui allouer une 
énergie propre, on lui attribue un processus 
indépendant. La communication est asyn- 
chrone, ce qui nécessite un mécanisme de 
sérialisation des acteurs qui associe à chaque 
acteur une file gérée par un arbitre et qui 
contient les messages arrivés et en attente 
d’être traités. 

Cette file est en fait le point d’entrée de l’ac- 
teur qui est référencé dans toute l’applica- 
tion par une forme contenant l’identification 
de la file et du processus. Ce mécanisme de 
sérialisation des messages a donné le qualifi- 
catif de sérialisé à un acteur pour lequel Puti- 
lisateur exige explicitement une puissance 
de calcul; cet acteur sera généralement un 
acteur dont le comportement est modifiable. 
En outre, lors de l'évaluation d’une forme 
d'expression du parallélisme contenant un 
acteur pur, une instance de cet acteur sera 
implicitement créée avec une puissance de 
calcul indépendante. 

Ainsi à tout instant de son exécution, une 
application en AL 1 a ses données réparties 
entre divers acteurs et le contrôle est lui aussi 
distribué entre les différents acteurs actifs. 
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Les communications en AL1 s'effectuent au 
moyen de trois types de transmissions : 

e Jes transmissions non blocantes qui per- 
mettent de réaliser des calculs parallèles 
(ŒORK); l'acteur, site de la transmission, 
poursuit son exécution parallèlement à 
lPévaluation de cette transmission. 

e les transmissions blocantes où l'émetteur 
attend une réponse pour continuer son exé- 
cution; elles sont implémentées par le 
mécanisme de capture de continuation en 
PLASMA. 

e les transmissions de “type futur” que l’on 
pourrait qualifier de blocantes par nécessité. 
En effet, l'émetteur ne se met en attente du 
résultat de la transmission que lorsque ce 
résultat devient nécessaire à la poursuite de 
ses calculs. 


Nous avons implémenté les mécanismes de 
changement de comportement, de priorité 
des messages et d'acteurs standard de paral- 
lélisme sur une version de la machine LILA 
étendue sous UNIX en utilisant les primitives 
de tubes et de fourches. Le pouvoir d’expres- 
sion d’AL I a été mis en évidence par la pro- 
grammation de multiples exemples classi- 
ques d'applications réparties. Il est alors 
apparu indispensable de concevoir une nou- 
velle machine considérée comme un réseau 
de machines virtuelles communiquant par 
messages et pouvant être distribuées sur 
divers types d’architectures matérielles, 


MACHINE VIRTUELLE MVR1 

Ce réseau de machines est appelé MVRI. 
Chaque machine virtuelle est implantée sur 
un processeur physique déterminé et peut 
exécuter plusieurs acteurs en temps partagé 
avec les mécanismes classiques de priorité, 
section critique, etc, Un acteur peut envoyer 
un message à un autre acteur situé sur l’une 
quelconque des machines virtuelles, 
Chaque machine virtuelle a une structure 
comparable à celle de la machine virtuelle 
LILA qui servait de support pour le dévelop- 
pement des interprètes d’acteurs séquen- 
tiels. Il s’agit d’une machine de traitement de 
liste dotée d’un langage de type assembleur 
récursif capable de gérer simplement des 
continuations, L'avantage principal de ce 
langage est qu’il peut être transformé en 
code assembleur efficace ou en langage évo- 
lué par simple macrogénération. Sa syntaxe 
entièrement parenthésée permet un prétrai- 
tement par un langage applicatif pour réali- 
ser des optimisations et tenir compte des 
SrAenIEEques propres à chaque machine 
Cible. 


COMPILATION DE PLASMA 

Nous étudions actuellement la construction 
d’un compilateur pour le langage PLASMA, 
composante séquentielle des langages d’ac- 
teurs, engendrant du code pour la machine 
virtuelle LILA. Cette compilation s’effectue 
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suivant une démarche analogue à celle de la 
compilation de LISP, mais à s’y ajoute un 
ensemble de problèmes originaux comme la 
compilation du filtrage, des transmissions, 
des fermetures et des continuations. En 
revanche, à l'inverse de la majorité des dia- 
lectes LISP, PLASMA est un langage à liaison 
statique ce qui est un avantage pour la com- 
pilation. 

Nous avons, dans un premier temps, défini 
une méthode de compilation des filtres et 
obtenu un compilateur de ces filtres, de 
structure équivalente à celle de interprète, 
par redéfinition des fonctions d’un inter- 
prète du filtrage. Ainsi, la compilation des 
divers types de filtres permet d’aborder la 
compilation de certaines structures comme 
la conditionnelle, 

De façon à profiter des avantages qu’offre le 
langage, le compilateur est lui-même codé 
en PLASMA. Il peut ainsi se compiler lui- 
même. 

Nous terminons actuellement la compila- 
tion des autres mécanismes et étudions l’in- 
tégration du compilateur dans l’environne- 
ment de PLASMA. 


ENVIRONNEMENT DE PROGRAMMA- 
TION 

Les études sur l'élaboration d’un environne- 
ment de programmation du langage AL 1 
s'appuient sur les systèmes de trace du lan- 
gage PLASMA dans ses diverses implémenta- 
tions et notamment en LILA sur MAC 
INTOSH, L'environnement de programma- 
tion du langage AL 1 est développé sur la 
machine MVR I elle-même installée actuelle- 
ment sur un réseau de stations SUN, La pre- 
mière phase entreprise est d'utiliser les mul- 
tiples possibilités des stations SUN, notam- 
ment en matière de gestion de fenêtres à 
écran (modules SUN VIEW) afin de per- 
mettre à chaque acteur d’une application de 
disposer si nécessaire d’une fenêtre à l'écran 
qui servira d'interface entre l'acteur et lutili- 
sateur. 

Dans la programmation concurrente, on 
rencontre de nouveaux problèmes liés à 
lordre partiel des événements. Ceci conduit 
à définir la nature des informations à conser- 
ver au cours d’une exécution et à étudier les 
différents choix de représentation de la 
trace. 


CIEL : CLASSES ET INSTANCES EN 
LOGIQUE 

Découlant de l’expérience acquise avec 
ALOG, extension de PLASMA au traitement 
de la logique, CIEL est un PROLOG quiintro- 
duit la notion de classes et d’instances. Il pré- 
sente à la fois les caractéristiques d’un Janga- 
ges à types polymorphes permettant une 
programmation générique et les caractéristi- 
ques d’un langage à objets avec un méca- 
nisme de classes et d’instances et la notion 
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d’héritage. La définition d’un objet CIEL 


comporte d’une part un ensemble de varia- * 


bles logiques typées locales, et d’autre part 
un ensemble de méthodes prédicatives défi- 
nies par des clauses de HORN. Chaque 
variable logique est typée par le nom d’une 
classe ou par une variable logique, ce qui per- 
met de définir des classes génériques para- 
métrées par d’autres classes. Toutes les 
méthodes d’une classe sont automatique- 
ment typées par un algorithme d’unification 
qui détermine leur type le plus général. 


Réalisations 

logicielles 

Les logiciels suivants sont des prototypes 
maintenus, diffusés avec manuel d’utilisa- 
tion : 

LILA Machine virtuelle pour l'écriture d’in- 
terprètes de langages applicatifs. 

Version C sur VAX, SPS7, SPS9, SUN. 
Version multifenêtre sur MAC+. 

La machine LILA est le support des interprè- 
tes. 

PLASMA acteurs séquentiels. 

ALOG extension de PLASMA avec 
traitement de la logique, 


ACTOR version parallèle de PLASMA utili- 
sant processus et pipe-line UNIX. 


CIEL Tnterprète disponible uniquement sur 
MAC+, 


Logiciels en cours de développement 


MVRI Machine virtuelle dérivée de LILA 
répartie sur un réseau de stations de travail 
SUN. 


ALI langage d'acteurs implémenté sur 
MVRI. 


PLASMA le compilateur, 


Perspectives futures 
Dans une première étape, l’équipe s’inté- 
resse à l’implémentation du langage AL 1 sur 
la machine MVRI1, en lui associant un envi- 
ronnement d’aide à la mise au point des pro- 
grammes. Ensuite la machine virtuelle 
MYRI sera implémentée sur une architec- 
ture multiprocesseur de type Transputer. 
Enfin, la compilation de PLASMA sera éten- 
due à la version répartie. 
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Les Avancées en Prolog III 


Les fondements 
de Prolog li 


Prolog a été initialement conçu pour le trai- 
tement des langues naturelles. Prolog Ill per- 
mettra un traitement intelligent de connais- 
sances plus diverses, y compris celles qui 
font intervenir des données numériques. 
Essentiellement, il sera capable de traiter au 
niveau de lPunification : 


e Les arbres infinis (créés par bouclage) qui 
seront munis de relations d'égalité et de dif- 
férence. 


e Leslistes dotées de l’opération de concaté- 
nation x. y où i, la taille de la liste x, doit être 
précisée par la contrainte x:i, et doit être con- 
nue au moment de son écriture. Une liste est 
un arbre dont le sommet initial est étiqueté 
par le symbole <>. On la note <aj, 42, 
an> OÙ af, a2,...., An est la suite de ses fils 
immédiats. L’entier n, qui peut être nul dans 
le cas de la liste vide, est la longueur de la 
liste, La concaténation se définit simple- 
ment par <a1,...., Am>.<b,.…., bn>=<a.… 
Am, Dh, Dn>. 

e Les nombres rationnels munis des opéra- 
tions d’addition, de soustraction, de multi- 
plication par une constante et des relations 
=,=, &, >,2>. Ces nombres seront traités 
Fons des arbres réduits à de simples feuil- 
es. 


e L’algèbre de boole complète avec toutes 
ses opérations et les relations =, =, et = 
(entraîne). Ici aussi les valeurs vrai et faux 
notées respectivement 1 et 0 sont considé- 
rées comme des feuilles d’arbres. 


Dans ce Prolog, un programme est un 
ensemble de règles. Chacune est de la for- 
me : POP]... Pm, B et se lit : sous réserve que 
Pensemble B de contraintes soit satisfait, po 
est vrai si p1 et..et Pm SOnt tous vrais OU, 
dans une interprétation plus opérationnelle : 
pour exécuter po, il faut l’ensemble B des 
contraintes, puis exécuter successivement po 
et...et Bm. 


Le mécanisme de base de la machine Prolog 
correspondante se résume en trois lignes : 
{1) (ao a1-.Gn, À) 

(2) (po + P1..Pm B) 

G) (1... Pm 41... An À U BU {po = ao}) 

La ligne (1) représente l’état de la machine à 
Vinstant t, la ligne (3) l’état de la machine à 
linstant t-+1 et la ligne (2) la règle utilisée 
pour ce changement d'état. Les pi et les qj 
sont des termes, À et À U BU {po= go} sont 
des ensembles de contraintes qui admettent 
au moins une solution. 


Récupération 
de mémoire 
en PROLOG Hi 


Un récupérateur de mémoire s’est avéré 
indispensable pour PROLOG III. Cette con- 
trainte nous a conduit à définir un interpré- 
teur avec recopie utilisant deux piles : 

e une pile de recopie, 

e une pile de restauration. 


À chaque unification, la règle utilisée, pour 
effacer un but, est dupliquée dans la pile de 
recopie. Cette pile contient en outre les sau- 
vegardes des points de choix pour simuler 
lindéterminisme. 

La pile de restauration est constituée d’une 
suite de doublets <adr, cont> appelés sou- 
venirs, où adr est l'adresse d’une cellule de la 
pile de recopie qui a été modifiée et dont le 
contenu de cette cellule avant cette modifi- 
cation. Pour le retour arrière, il suffit de 
remettre ces anciennes valeurs aux adresses 
indiquées pour actualiser la pile de recopie. 
Après l'effacement de certains buts, on peut 
mettre en évidence les seules structures uti- 
les pour la suite de l’interprétation. La récu- 
pération de mémoire se charge donc de réor- 
ganiser la mémoire en compactant chacune 
des deux piles. 

La récupération de mémoire se fait en trois 


. étapes : 


1. COLLISION DE SOUVENIRS 

ET CHAINAGE DE L'HISTORIQUE 

Lors d’une même unification, une même 
cellule a pu être modifiée plusieurs fois. Seul 
le souvenir le plus ancien est utile pour le 
retour arrière, En parcourant la pile de res- 
tauration, d’une part, on élimine les souve- 
nirs inintéressants et d’autre part, on met en 
place un chaînage de toutes les valeurs prises 
par une cellule de la pile de recopie pendant 
Pexécution du programme, Cet “historique” 
permet de “simuler” un backtracking lors de 
la deuxième étape, 


2. ÉPURATION DE L'HISTORIQUE 

ET MARQUAGE DES STRUCTURES 
VIVANTES 

Cette étape permet de marquer la résolvante 
courante ainsi que les résolvantes mémori- 
sées dans les différents points de choix. On 
remarque lors du marquage que l’historique 
doit être épuré dans certains cas. Le mar- 
quage est lié à un point de choix en commen- 
çant par le point de choix le plus récent. On 
élimine de Phistorique toutes les valeurs ne 
concernant pas le point de choix à partir 
duquel se fait le marquage. A la fin de cette 
étape, seules les cellules utiles des deux piles 
sont marquées. Il s’agit alors de compacter 
ces deux piles. 
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3. COMPACTAGE SELON 
L'ALGORITHME DE MORRIS 

Cet algorithme compacte la mémoire en 
mettant à jour les pointeurs. Parmi les diffé- 
rents algorithmes qui permettent d'effectuer 
ce travail, deux ont été retenus : MORRIS et 
JONKERS, d’une part, parce qu’ils conser- 
vent l’ordre linéaire des cellules vivantes 
après compactage, d'autre part, pour leur 
coût réduit en mémoire supplémentaire. Ils 
sont tous deux basés sur le même principe. 
L’algorithme de MORRIS a été préféré à celui 
de JONKERS parce qu'il est plus performant 
sur les structures manipulées par PROLOG 
IL 


En voici une description rapide, On consi- 
dère une suite de cellules A, B, C,.., qui 
pointent toutes vers une même cellule T. On 
retourne successivement chacun des poin- 
teurs afin d’obtenir une liste (qui démarre de 
T) de toutes les cellules qui, initialement, 
pointaient vers T, L'information qui, initiale- 
ment, se trouvait en T a été déplacée de 
façon à se trouver après le premier traite- 
ment, dans la dernière cellule de la liste. 
Dans un deuxième temps, quand on connaît 
la nouvelle position de T, soit T”, on réactua- 
lise chacune des cellules de la liste en la fai- 
sant pointer vers T’et on retransporte l’infor- 
mation placée dans la dernière cellule, à sa 
place initiale soit T. 


L’algorithme parcourt deux fois la zone 
mémoire : Le premier passage se fait dans le 
sens du compactage, le second en sens 
inverse. Chacun ne s'intéresse qu'aux poin- 
teurs dans le sens du passage courant et, par 
conséquent, ignore à la fois les données (non 
pointeurs) et les pointeurs en sens inverse, 
Le compactage ne se fait effectivement 
qu’au cours du second passage, 


Pour l’implémentation, il est nécessaire de 
reconnaître : 

e une cellule vivante, 

sun pointeur, 

os un pointeur retourné. 

Pour des questions d'efficacité, on a choisi 
d'utiliser trois tableaux de bits extérieurs 
pour coder ces informations, On testera suc- 
cessivement des vecteurs de 32 bits pour 
trouver rapidement la prochaine cellule 
vivante, 

D'autre part, on utilise un compteur, initia- 
lisé au nombre de cellules à récupérer (cal- 
culé lors du marquage) et incrémenté après 
le traitement d’une cellule vivante, qui per- 
mettra de connaître rapidement la nouvelle 
position de chacune d'elles, 


Il reste maintenant à décider quand lancer le 
processus. Plusieurs possibilités sont offer- 
tes : 

e lorsqu’une certaine borne limite de la pile 
de recopie est afteinte ou dépassée ; 

e lorsqu'un certain pourcentage de a pile a 
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été occupé, à partir du dernier appel du pro- 
cessus de récupération de mémoire; 

e par programme, c’est-à-dire par l’efface- 
ment d’une règle prédéfinie, 


Traitement des listes 
en PROLOG NRI 

1. LES INTERPRÉTEURS DE PROLOG 

a) Les interpréteurs à structure partagée 
(structure sharing) où l’on ne crée À chaque 
résolution que les variables apparaissant 
dans la règle appliquée (c’est à cette famille 
qu’appartient Prolog II, développé par le 
GIA). 

b) Ceux qui fonctionnent par recopie de ter- 
mes (structure copying) où leffacement 
d’un but se fait à l'aide d’une copie de la règle 
à utiliser. 


Le principal avantage des interpréteurs du 
type 1 est leur faible consommation de 
mémoire par rapport aux interpréteurs du 
type 2 qui en sont très gourmands. En con- 
trepartie, les algorithmes intervenant dans 
les interpréteurs du type 1 sont plus com- 
plexes et plus lents que ceux du type 2 (les 
termes et variables sont plus difficiles 
d'accès). 

Le nouvelinterpréteur devant comporter par 
ailleurs des algorithmes d’unification déjà 
complexes, il était nécessaire de choisir le 
mode de fonctionnement 2, quitte à implé- 
menter un algorithme de récupération de 
mémoire (garbage collector) pour compen- 
ser la dépense excessive de mémoire. 

La première maquette, écrite en Pascal, a 
permis de tester la faisabilité de ce nouvel 
interpréteur. Il était néanmoins intéressant 
de pouvoir en évaluer ses performances. 
Une autre maquette partielle de l’interpré- 
teur Prolog, écrite en langage C, avec de nou- 
velles structures de données plus proches du 
mot-machine a donné de très bons résultats 
puisque sa vitesse d’exécution est de l’ordre 
de celle de Prolog Il. 


2. GESTION DE LA MÉMOIRE POUR LE 
NOUVEAU PROLOG 

Le nouvel interpréteur nécessite dans sa 
version de base, l’utilisation de 2 piles princi- 
pales et de 2 piles secondaires (4 piles secon- 
daires dans la maquette courante, plus com- 
plète). Pour avoir une meilleure répartition 
de la mémoire entre ces piles, il est indispen- 
sable de les allouer dans une zone unique, en 
ne fixant aucune autre borne que celles de la 
zone eten permettant aux piles “intérieures” 
d’être translatables. 

Cette gestion des piles permet de retarder 
lappel au compactage mémoire, assez lent 
mais cependant indispensable, 
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3. NOUVELLES STRUCTURES 

DE LISTES POUR PROLOG 

Les listes sont des structures très utilisées 
dans Prolog. Il est donc nécessaire d’optimi- 
ser les algorithmes permettant leur traite- 
ment en définissant de nouvelles structures 
et de nouveaux opérateurs que ceux existant 
dans d’autres dialectes de Prolog, Les opéra- 
tions les plus fréquentes sur les listes sont les 
suivantes : 


a) Accès au premier élément et au reste 
d’une liste (ces deux opérations de base sont 
Rene à la plupart des interpréteurs pro- 
log). 

b) Concaténer deux ou plusieurs listes. 

c) Accéder au n°"° élément d’une liste, 

d) Calculer la taille d’une liste, 


On peut ajouter Le point suivant : les chaînes 
de caractères sont indispensables à Penvi- 
ronnement. On souhaite, pour les manipuler 
plus aisément et bénéficier du traitement de 
liste, les assimiler à des listes de caractères, 


Rappelons que les opérations des points b, c, 
d se programment récursivement dans les 
prologs classiques à laide des deux opéra- 
tions du point a. Ce sont donc des opérations 
habituellement coûteuses en temps. 


Nous avons défini de nouvelles structures de 
liste ainsi que les algorithmes permettant de 
traiter efficacement les points b, c, d au 
niveau de l’interpréteur Prolog. 

e On note <a... aÿ> et on appelle liste de 
taille n la suite ordonnée des éléments 
Aie Qype 

e On note <> la liste vide. 

Soit “” (point ou concaténation) l'opérateur 
binaire associatif dont les opérandes sont des 
listes, défini par : 

pion And, bye = <a], .…., an, 
bp, bm> 

et, pour toute liste /: 

<>i= <> = 

On établit les restrictions suivantes : 

e dans toute expression 4.b, a et b doivent 
être des listes, et la longueur de a doit être 
connue, 

e pour toute équation z = 4.b, il ne faut pas 
que z “termine” b, afin de ne pas créer de liste 
infinie par bouclage. 


4. RÉSOLUTION D'UN SYSTÈME 

DE CONTRAINTES SUR LES LISTES 
DOMAINE : 

Soit C un ensemble de constantes. 

Soit Ÿ un ensemble de variables. 

Soit D = CU VU L, pour tout entier 
ñ > 0, les Ln étant définis plus bas. 

Soit Ln l’ensemble des listes de taille » de la 
forme : 

<ap...@n> pour n > 0, les appartenant à D. 
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TRAITEMENT DU SYSTÈME : 

On note ! : n la contrainte imposant à / d’être 
une liste de taille 7. 

Soit S un ensemble de contraintes de la 
forme {1 = 12 ou bien { : n, avec /1, 2 des élé- 
ments de D, » un entier positif ou nul. 
Simplifier le système S consiste à Le transfor- 
mer en système S’équivalent vérifiant la pro- 
priété suivante : 

Les équations de S” sont de la forme v = /, 
avec ve Vet / e D, où la variable v n'apparaît 
en membre gauche dans aucune autre équa- 
tion de S”. 


On transforme le système 5 en 5’ en effec- 
tuant les opérations suivantes : 

05" est vide au départ. 

° On enlève de S les contraintes de la forme 
ln, en vérifiant ou en imposant que / soit 
une liste de taille n. À ce moment, les restric- 
Hors énoncées plus haut doivent être respec- 
tées. 

e On passe ensuite aux équations : tant que S 
n’est pas vide, on lui enlève une équation 
11 = 12 et on la traite (paragraphe suivant). 


5. RÉSOLUTION D'ÉQUATIONS SUR LES 
LISTES 

On ne s'étendra pas sur le traitement de ces 
équations. On ne donnera qu'une vague idée 
des algorithmes permettant le traitement des 
principaux types d'équations. Si équation à 
traiter est de la forme : 

e ab = u.v avec a une liste de taille n, u de 
taille m, avec m=0etn=0 (si par exemple on 
a n = 0 on a en fait à résoudre l'équation 
b=u.y). 

On impose ou on vérifie - selon qu’ils sont 
libres ou pas -, que b et v sont des listes. 
Sin=m, on ajoute à S les équations a =u et 
b = v sinon supposons n < m (si n > m, on 
traite Péquation u.v = a.b). 

On introduit la variable f à qui on impose 
d’être une liste de taille m-n. 

On ajoute au système S les équations : 

u eu 





Fv 

qui seront traitées plus tard. 

e <a. an = <bp.sbm> 

on vérifie que » = m, puis on ajoute à S les 
équations a; = b;. 

e <AjAn> = 4.b 

on ajoute à S l'équation <a, an>.<>=a.b 
(on se ramène en fait au premier cas). 


6. STRUCTURES INTERNES UTILISÉES 
On utilise 2 structures internes pour repré- 
senter les listes en mémoire : 

e La structure représentant la liste d’élé- 
ments contigus <aj,…,an>, est un doublet 
formé de l’entier » et d’un tableau de poin- 
teurs sur les éléments a;. 

e Une autre structure qui représente l’ex- 
pression a.b. C’est un doublet de pointeurs 
sur les listes a et b. 


Algorithmes 

de résolutions 
d'équations sur les 
arbres et les listes 


Il s’agit de prolonger l'algorithme classique 
de résolution de systèmes d’équations et 
d’inéquations dans l'algèbre des arbres, pro- 
posé par Alain Colmerauer (Equations et 
Inéquations sur les Arbres, 1984) afin de 
pouvoir manipuler plus aisément certains de 
ces arbres, les listes. 


1. STRÜUCTURE 

Nous nous sommes placés dans l'algèbre des 
arbres dans laquelle nous avons introduit les 
opérations “” et “L,”, n>0, respectivement 
binaire et n-aires. “b” étant une opération 
binaire particulière de notre algèbre, et 
apan n arbres de son domaine, l'arbre 
bayba2..ba,Lo est une liste de longueur n 
(Lo est la liste de longueur nulle). 

e L'opération de concaténation “” fait cor- 
respondre à 2 arbres À et B, À de la forme 
bajbap...banLo l'arbre .AB=bajba)...ba,B. 
e Les opérations d'assemblage “L”, n > 0, 
construisent à partir de » arbres a7,….,ay 
larbre L,aj...a,=baba..baLo. 


2. SYSTÈMES D'ÉQUATIONS 

Si Fest l’ensemble des symboles fonction- 
nels associés aux opérations de notre 
algèbre, et Vun ensemble infini de variables, 
un terme test une suite finie d'éléments jux- 
taposés de FU V. X étant une affectation de 
l’ensemble des variables, et tun terme quel- 
corque : 

e soit est réduit à une variable x, et {/#=x/X, 
esoit t=ftytm f= à et XX tn lX Si 
ul X,..,tn1/X et t/X sont définis, 

e soit 1—.uv, et /X=.u/X*/X est une liste de 
longueur finie et si v/X est défini. 

Dans tout autre cas, /X n’est pas un élément 
du domaine de notre algèbre. 


Un système d’équation $ est composé d’un 
ensemble fini d'équations plongé dans un 
ensemble d’affectations C, son contexte, tel 
que quel que soit # une affectation de C, et 
quel que soit un terme figurant dans S, tx 
est un élément du domaine de notre algèbre. 


Pratiquement, nous utiliserons pour décrire 
nos contextes, des contraintes de longueur 
de la forme Listeg(1), K>0. Une affectation X 
satisfait la contrainte Listek(t) si t/x est une 
liste de longueur &. 


Un système d'équations est donc un 
ensemble d’adéquations et de contraintes de 
longueur. Afin de conserver à notre algo- 
rithme sa simplicité, nous exigerons que 
pour tout terme .wv figurant dans un système 
d'équations S, il existe k, k>0, tel que, soit 
débute par le symbole fonctionnel L}, soit S 
contient la contrainte Listep(u). 
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3. ALGORITHME DE RÉDUCTION 

Notre but est de déterminer si un système 
d'équations £ est soluble ou non, et s’il est 
soluble de mettre en évidence ses solutions, 
Pour cela, notre algorithme tente de pro- 
duire un système d'équations sous forme 
“réduite” R, équivalent à Eau moins sur l’en- 
semble des variables figurant dans ce der- 
nier. S’il y réussit, £ est soluble et nous pou- 
vons décrire ses solutions à laide de À, sinon 
E est insoluble. 


& est un système d’équations dont, d’une 
part, les membres gauches d'équations, et 
d’autre part, les termes figurant à l’intérieur 
de ses contraintes de longueur, sont des 
variables distinctes. À toute affectation X des 
variables de qui ne figurent pas en membre 
gauche d’équation, satisfaisant les contrain- 
tes de longueur de R, correspond une affec- 
tation Ÿ unique des variables figurant en 
membre gauche d’équation telle que XU Y 
soit solution de R. 


4, EXEMPLE 

Nous nous limiterons à des systèmes d’équa- 
tions dans lesquels le symbole fonctionnel 
“b” n'apparaît pas, et pour tout terme de la 
forme .st, soit s débute par un symbole fonc- 
tionnel “Lx”, soit s est une variable (on peut 
facilement modifier un système d'équations 
quelconque afin qu'il satisfasse ces restric- 
tions). Nous écrirons alors s.1 le terme .st 
sans risque d’ambiguité. 


Soit à réduire le système d'équations : 

E ={fax;=fx2Lgabc, yi.y2=21.Laabcd, Lis- 
tes(y1), Liste)(z1)} 

Notre algorithme produit le système d’équa- 
tions soluble 

R = {Listes(yy), Listep(z), Listez(u), x2=a, 
xy=Lzabe, yy=zju, u=L3abc, y2=Lid} 
équivalent à Æ sur l’ensemble de variables 
{XL X2, Y1 V2 21). 


Traitement 

des contraintes 
numériques 

Nous ne nous intéressons qu'aux contrain- 
tes numériques linéaires, c’est-à-dire à une 
suite d'équations et d’inéquations de la 
forme : 

b+Ziax=0, 

b+Ziax; > Oou, 

b+Ziax>0, 

où les x; sont des variables de type arithméti- 
que, les a; et b des coefficients numériques. 
La méthode adoptée pour vérifier qu’un sys- 
tème de contraintes arithmétiques est 
soluble ou pas, repose sur l’algorithme du 
Simplex de G.B. Dantzig, avec traitement 
des cas de dégénérescences. 


Le traitement des contraintes de type = 
d’une part, et la propagation des erreurs d’ar- 


rondis sur les flottants provenant des calculs 
propres au Simplex d’autre part, nous ont 
amené à restreindre notre domaine de travail 
aux nombres rationnels. En conséquence, 
une arithmétique fonctionnant en précision 
parfaite a dû être écrite. 


1. L'ARITHMÉTIQUE 

Pour des raisons d’efficacité et d’occupation 
mémoire, le codage des rationnels en déve- 
loppement en fractions continues a été aban- 
donné au profit d’un codage plus classique 
sous forme d’un couple d’entiers (numéra- 
teur et dénominateur). Une première réali- 
sation a permis de constater que pour cer- 
tains problèmes, la taille des nombres 
entiers disponibles sur machine s’avérait 
tout à fait insuffisante ; Parithmétique a donc 
été étendue aux entiers non bornés, 


Plusieurs structures pour le codage des diffé- 
rents types de constantes numériques ont 
été étudiées, et c’est finalement par une suite 
contiguë de mots machine de 32 bits que les 
constantes ont été représentées. Ce codage 
présente lavantage de manipuler des struc- 
tures simples, conformes à celles utilisées 
par linterpréteur, il permet de minimiser la 
place occupée par les entiers et les ration- 
nels, surtout lorsqu'il s’agit de petits entiers 
ren à 2%) qui restent de loin les plus 
réquents. Enfin, c’est avec ce codage que 
nous avons jusqu’à maintenant pu réaliser 
les meilleures performances pour les calculs 
arithmétiques. 


2. LE TRAITEMENT DES CONTRAINTES 
nitialement, le système S de contraintes est 
vide. Chaque fois que l’on ajoute une con- 
trainte ç au système S, on applique au sys- 
tème SU{c}une suite de transformations qui 
produit un système équivalent S’, pour 
quel on peut décider s’il est soluble ou pas. 
Les contraintes arithmétiques de type = ne 
aisant pas l’objet d’un traitement particulier 
par rapport aux contraintes du même type 
sur les arbres, leur résolution se fait au 
niveau de l’interpréteur. 


On peut distinguer quatre phrases principa- 
es dans ce traitement : 

. mise sous forme normale des contraintes, 
2. réduction du système de contraintes S, 
3. réduction du sous-système S* de S (pro- 
cessus Simplex), 

4. élimination des variables figées. 





a. MISE SOUS FORME NORMALE 

Les inéquations du type > et> sont tradui- 
tes par une équation de la forme 
b+Zjax=ut 

où u* est une variable d’écart introduite, 
astreinte à être non négative. Si Pinéquation 
est a type > on produit aussi la contrainte 
u'=t. 


La forme normale d’une contrainte estx==r, 
où 

(1) xest une variable qui ne figure pas dansr, 
2) rune expression arithmétique simplifiée, 
6) x» y pour toutes les variables y de r (“»” 
étant la relation d’ordre établie sur les varia- 
bles au niveau de l’interpréteur avec la res- 
triction suivante : x » y si x est une variable 
arithmétique et y une variable arithmétique 
astreinte à être non négative), 

Par exemple, la forme normale de la con- 
trainte 2x + 3y-2 > 0 sera 
x=-3/2y+1+1/2u* six» you 

y =-2/3x + 2/3 + 1/3u* siy»x, 


Chaque contrainte est alors mémorisée sous 
sa forme normale (équation) et codée dans 
Pespace des règles comme une suite de dou- 
blets adresse-variable, adresse-coefficient 
(les monômes dont Le coefficient est nul ne 
figurent pas dans l'expression). 


b. RÉDUCTION D'UN SYSTÈME 

DE CONTRAINTES 

Un système $ de contraintes aritimétiques 
est sous forme réduite s’il est de la forme 
us tn... , Xn = tn) | 

et s’il satisfait aux conditions suivantes : 
(1) toutes les variables de S sont de type 
arithmétique, 

@) Lo contraintes de $ sont sous forme nor- 
male, 

G) les x; sont des variables distinctes d’une 
contrainte à l’autre, 

(4) le sous-système S* de S contenant les 
contraintes x;*==t;avec x; non négative peut 
se mettre sous forme réduite dans la struc- 
ture des variables astreintes à être non néga- 
tives. 


Réduire le système $ U {ce} où $ est sous 
forme réduite et c une contrainte du type 
s=t, produite au cours de l’unification, c’est 
substituer dans s et dans t chaque occurrence 
de variable par le membre droit de l'équation 
qui définit cette variable dans S, tant que cela 
est possible, et mettre l’équation obtenue 
sous sa forme normale e’. Dans le cas où le 
système initial de contraintes contient des 
inéquations du type > ou >, cette réduction 
vise à éliminer les variables non astreintes à 
être non négatives. 


L’équation obtenue e peut avoir quatre for- 
Mmes : 

(D) © est trivialement insatisfaisable (k = 0, 
K constante non nulle), $ U {c} n’a pas de 
solution, 

Q) c’ est trivialement satisfaisable (0 = 0), le 
système obtenu S’ est sous forme réduite et 
dans ce cas S =$, 

G) © est de la forme x == r (x non astreinte à 
être non négative), le système S’ est équiva- 
lent à S U{c} et est sous forme réduite (sous 
réserve que toutes Les contraintes de type = 
liées à la variable x soient vérifiées), 

(4) © est de Ia forme x* == r (toutes les varia- 


Li 
Le 


L'INTELLIGENCE ARTIFICIELLE 


ET OUTILS POUR 


D! 
Oo 


LANGAGES 


ARCHITECTURE DE MACHINES 


Les avancées en PROLOG II 


bles de c’ sont astreintes à être non négati- 
ves), le processus Simplex est activé, il per- 
mettra de dire si S U {e} est équivalent à un 
système S’ sous forme réduite. 


La simplification d’une expression arithmé- 
tique a fait l’objet d’une étude particulière 
afin d’en améliorer les performances, les dif- 
férents exemples testés ayant montré que ce 
traitement intervenait un très grand nombre 
de fois au cours de la mise sous forme nor- 
male et se révélait d’un coût non négligeable. 


c. RÉDUCTION DU SYSTÈME S* 

Le système S* est sous forme réduite dans la 
structure des variables astreintes à être non 
négatives s’il est de la forme : 

(ae bi + Zi ai Xp; Yn = bn + 2j nj Xj} 
et s’il satisfait aux conditions suivantes : 
(1) S* ne contient que des variables astrein- 
tes à être non négatives, 

(2) pour chaque équation, y] et les x; sont des 
variables distinctes, 

(3) les y1 sont des variables distinctes entre 
elles et ne figurent dans aucun membre droit 
des équations de S*, 

(4) les b; sont des constantes arithmétiques 
non négatives, 

(5) Le système S* ne contient pas de variables 
figées (variable qui prend la même valeur 
pour l’ensemble des solutions de S*). 


La réduction du système S* U {e} où S* est 
sous forme réduite et e une équation de la 
forme b+Z;a;x;=0 (kconstante numérique 
pouvant être nulle, x; variables astreintes à 
être non négatives) se déroule en deux pha- 
ses, tout d’abord la mise de e sous une forme 
normale e” pour le système S+, puis l'appli- 
cation d’une suite de transformations au sys- 
tème S*{U {e’} pour obtenir un système S*?, 
soit sous forme réduite dans la structure des 
variables astreintes à être non négatives, soit 
non soluble. 


aa) Mettre e sous une forme normale pour 
S*, c’est substituer chaque variable x; de e 
par Pexpression e; si l'équation x; = e; figure 
dans S* et simplifier l’expression obtenue; 
deux cas de figure peuvent se présenter pour 
l'expression simplifiée eo : 

(1) il existe au moins une variable y de ep qui 
ne figure pas dans l’ensemble constitué des 
variables des équations S*, l'équation y =b° 
+ Z'ia;x;estune forme normale de e pourS*, 
elle est ajoutée à S', 

(2) toutes les variables de eg figurent déjà 
dans l’ensemble constitué des variables des 
équations de S*, on élimine d’abord de S* 
toutes les équations que l’on peut atteindre 
par une variable quelconque de ep, puis on 
ajoute e, sous une forme normale au nou- 
veau système S* (les équations éliminées, 
qui pourront toujours s’écrire sous forme 
normale, seront retraitées par la suite). 


bb) Les transformations de S* [J {e’} sont 
effectuées au moyen de l'opération de pivot 
selon la méthode de Gauss-Jordan et doi- 
vent respecter les trois critères suivants : 
(1) conserver les constantes de S* non néga- 
tives (elles peuvent varier) pour pouvoir 
exhiber une solution particulière, 

@) ne pas introduire la variable figurant en 
membre gauche de e’ dans S* pour conser- 
ver la propriété : S* ne contient pas de varia- 
bles figées, 

(3) éliminer les cas de dégénérescences pour 
ne pas créer de cycles dans l'algorithme. Le 
choix du pivot permet de satisfaire ces trois 
critères. 


Ces transformations s’arrêtent lorsque €” est 
de l’une des trois formes suivantes : 
()y=b+Zia;x;avec betles a; strictement 
négatifs, le système S*” n’admet pas de solu- 
tions, 

(2) y=b + Zi aix; avec k strictement positif, 
le système S'”° est sous forme réduite dans la 
structure des variables astreintes à être non 
négatives donc soluble, 

G)y=Z;a;x avec les a;strictement négatifs, 
lesystème S*” est soluble (aux contraintes de 
type = près) mais il n’est pas sous forme 
réduite dans la structure des variables 
astreintes à être non négatives puisqu'il con- 
tient au moins y et les x; comme variables 
figées à zéro. 


d, ÉLIMINATION DES VARIABLES FIGÉES 


Dans le cas particulier où la terminaison des 
transformations aboutit à la détection des 
variables figées, il faut éliminer du système 
S* toutes les équations que lon peut 
atteindre par les variables de e”, puis retraiter 
successivement ces équations (à lexception 
de e’} afin de vérifier si d’autres variables ne 
se figent pas, auquel cas on réitère ce proces- 
sus. Ce traitement est indispensable pour les 
variables astreintes à être non négatives car 
l'information x = k (k constante non néga- 
tive) permet de relancer la vérification des 
contraintes de type -= liées à ces variables. 


Essentiellement, deux méthodes ont été 
étudiées pour réaliser ce traitement : 

e l’une qui consiste à supprimer de S* les 
équations à retraiter, ce qui est coûteux en 
temps (les structures utilisées pour le codage 
des éléments de S* sont complexes) et en 
place mémoire (de nombreuses modifica- 
tions doivent alors être mémorisées dans la 
pile de backtracking), mais qui présente 
l'avantage d’atléger temporairement le sys- 
tème S*, 

e l’autre qui se borne à marquer dans S* les 
équations à retraiter de façon à ne pas en 
tenir compte lors de la recherche du pivot, 
mais qui présente le gros inconvénient d’ef- 
fectuer les calculs sur les coefficients des 
équations qui n’ont pas encore été retraitées. 
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Ces deux méthodes ont jusqu’à maintenant 
donné des résultats comparables sur Le plan 
des performances. 


3. LE CODAGE DES ÉLÉMENTS DE S* 
Le choix desstructures a été fortement guidé 
par celui déjà fait au niveau de l’'interpréteur ; 
les différents éléments manipulés (variables 
et coefficients de S* principalement) sont 
donc représentés par une suite contiguë de 
mots machine dont le premier en détermine 
la nature. 

Les systèmes traités étant généralement très 
creux (variables peu liées entre elles) et fai- 
sant intervenir un nombre important de 
variables, une représentation matricielle 
classique sous forme de tableau était peu 
réaliste. En outre, un accès très rapide aux 
éléments d’une “ligne” ainsi qu’à ceux d’une 
“colonne” s’avérait d’une importance non 
négligeable (recherche du pivot, élimination 
des variables figées et marquage des élé- 
ments pour la récupération de mémoire 
entre autres). C’est donc un codage mixte 
conciliant ces deux aspects qui a été adopté, 
Il s’agit d’un chaînage horizontal et vertical, 
avant et arrière, des coefficients du système 
(seuls les coefficients non nuls sont mémori- 
sés), de plus, chaque coefficient possède un 
accès sur les variables dont il dépend. Ce 
codage permet de considérer le système sous 
sa forme duale ou primale. Une optimisation 
importante, liée aux structures, a été d’utili- 
ser deux listes distinctes pour représenter un 
vecteur de coefficients, l’une contenant les 
coefficients positifs, l’autre les négatifs, ce 
qui a permis de minimiser les parcours, le 
signe des coefficients étant un élément 
déterminant dans l’algorithme de recherche 
du pivot, 


Les contraintes 
Booléennes 


Pour en terminer avec ces nouvelles algè- 
bres, PROLOG lit sera donc capable de traiter 
des systèmes de contraintes booléennes, 
L'objet de ce chapitre est de présenter suc- 
cinctement la représentation et les algorith- 
mes de traitement de ce type de contraintes. 


1. LA REPRÉSENTATION DES 
CONTRAINTES BOOLÉENNES 

Ces contraintes seront représentées sous la 
forme d’équations booléennes du type : 
FSF où F et F' sont des formules booléen- 
nes et S un symbole relationnel, 

Dans cette représentation, les formules 
obéissent aux définitions classiques des wff 
(well formed formulae) du calcul proposi- 
tionnel muni des opérateurs décrits ci-des- 
Sous : 

e les constantes l’ (vrai) et (” (faux), 

e les opérateurs &, 1, — (respectivement et, 
ou, non), 


+ les symboles relationnels=,=, =(respecti- 
vement égal, différent et implique). 
Parailleurs, on utilisera des contraintes unai- 
res du type : A : booléen. 


2. LES ALGORITHMES DE 
RÉSOLUTION 

Le traitement de systèmes de ces contraintes 
booléennes au niveau de l’unification nous a 
amené à étudier divers algorithmes de vérifi- 
cation de cohérence d’ensembles de formu- 
les en calcul propositionnel. 


Pour être adapté à une utilisation répétée au 
sein même de l’interpréteur, l'algorithme 
choisi devait au moins remplirles conditions 
suivantes : 

e Efficacité maximale en temps de calcul sur 
des ensembles importants de clauses. 

e Nécessité d’être pourvu de fonctionnalités 
internes proches de celles de l’interpréteur. 
e Adaptañilité aisée aux structures de don- 
nées communes aux divers modules. 

La solution que nous avons adoptée s’inspire 
très fortement des travaux réalisés récem- 
ment par Pierre Siegel dans le domaine du 
calcul propositionnel. 

Il en résulte un algorithme utilisant à la fois 
la SL-Resolution (Kowalski-Küehner 1971) 
et des résultats concernant la production de 
clauses résolvantes incluses dans l’ensemble 
de clauses initial dans un but de simplifica- 
tion maximale du système courant. 


Très succinctement cet algorithme s'appuie 
sur les résultats suivants : 

Soit S un ensemble de clauses cohérent, Soit 
C une clause, Alors, en construisant une 
famille d’arbres de racine C, et en définissant 
une discrimination des littéraux de chaque 
clause de ces arbres en A-ancêtres, B-ancê- 
tres, littéraux en production et littéraux effa- 
cés, on montre que : 

@ Si S U C implique la clause vide alors on 
sait construire un arbre de racine C tel que 
tous les littéraux de C sont effacés. 

(ii) Pour toute clause C’impliquée par SUC, 
on sait construire un arbre de racine C tel 
que les littéraux en production sont exacte- 
ment ceux de C’. 

D'autre part, on sait que : 

(ü) Soit S un système, C une clause de S et 
C’ une clause contenue dans C alors les sys- 
tèmes S et S [J{C} - {C} sont équivalents. 
Ces résul-ats nous permettent donc de ne 
produire effectivement que des clauses qui 
minimisent le système initial. 


D'un point de vue développement, la mise 
en palce d’un tel algorithme, par un souci 
d'efficacité optimum, nous a conduits à 
l'étude de plusieurs points importants : 

() L’élabcration de structures de données 
complexes permettant, d’une part, le plus 
possible d’accès directs sur les variables, les 
clauses et les littéraux qui interviennent 
dans Parbre de résolution et, d’autre part, 


optimisation d’un grand nombre de primi- 
tives de calculs très souvent utilisées. 

(ii) La recherche du plus grand nombre pos- 
sible de méthodes ayant pour but de minimi- 
ser les parcours de ces familles d’arbres - par 
essence très coûteux - en éliminant certains 
points de choix inutiles. 

Ceci est réalisé, notamment, en éliminant 
physiquement les littéraux effacés, et en blo- 
quant au plus tôt les parcours amenant à la 
production de clauses dont on peut savoir, 
par avance, qu’elles seront peu intéressan- 
tes, généralement parce qu’elles ne sont 
incluses dans aucune clause du système ou 
bien du fait qu’une au moins des clauses pro- 
duites les contienne au sens large. 


3. PERSPECTIVES A COURT TERME 
Les travaux que nous menons actuellement 
dans le cadre de cette étude portent plus par- 
ticulièrement sur les points suivants : 

e La mise en place du lien qui devra être fait 
avec les autres modules décrits dansles para- 
graphes précédents. 

e La possibilité d'obtenir, à tout moment, un 
système simplifié, équivalent au système 
courant mais ne portant que sur un sous- 
ensemble des variables utilisées, 

e L'étude de la possibilité d’utiliser la récu- 
pération de mémoire en cours de traitement 
des contraintes booléennes. 


Collaborations 
industrielles : 
Participation au programme ESPRIT, 


Le GIA est l’un des contractants du projet 
P1219 (1106) intitulé : “Further development of 
PROLOG and its validation by KBS in techni- 
cal areas”. Dans ce projet, Le GIA a pour par- 
tenaires la société ProloglA (France) et les 
sociétés DAIMLER-BENTZ et Robert BOSCH 
(RFA). 

Jl s’agit de réaliser un système expert de dia- 
gnostic de pannes de voitures, écrit au 
moyen d’une version améliorée de PROLOG 
I. Dans ce cadre, le GIA doit ajouter à la ver- 
sion existante une arithmétique complète et 
Pintégration des contraintes numériques au 
mécanisme d’unification de PROLOG. 
DAIMLER-BENTZ et BOSCH utiliseront leur 
savoir-faire pour constituer la base de con- 
naissance et les règles d'expertise dans le 
domaine choisi. C’est sur ces deux préala- 
bles que sera construit le système expert 
envisagé. 

La société PROLOGIA commercialise diffé- 
rentes versions de Prolog sur plusieurs types 
de matériels : DEC, HP, SM90, IBMPC et 
compatibles, Apple IT, Macintosch.. 
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VLASP80 MOTS CLES 

aide à la documentation 

apprentissage (classification de concepts) 
architecture parallèle synchrone 
architecture pyramidale 

Common Lisp (langage de programmation) 
compréhension automatique de programmes 
environnements de programmation 
graphes de partition 

intelligence artificielle 

méthodes de programmation 

pour machines parallèles 

normalisation des langages 

prolog 
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Motivations de l’équipe : 

e L'étude et la réalisation d’interprètes à 
haut degré de portabilité de langages d’Intel- 
ligence Artificielle : COMMON-LISP, SCHEME, 
PROLOG. 

e La création de méthodes de programma- 
tion et de langages pour architectures paral- 
lèles synchrone à très grande échelle, machi- 
nes planes en grille où machines pyramida- 
les. 

e La réalisation d’environnements de pro- 


grammation, de mise au point, de communi- * 


cation, et de documentation associés. 
e La réalisation d'outils d’analyse et de com- 
préhension automatique de programmes. 


Langages 
d'intelligence 
Artificielle 


P. Greussay a développé en 1986 une version 
portable du standard LISP industriel COM- 
MON-LISP sous Unix. Écrite en langage C, 
ce système a été porté sur VAX, SUN, et SM- 
90. Greussay a également mis au point dans 
les mêmes conditions une version d'étude du 
langage PROLOG-2 de Marseille, qui en 
donne un modèle très précis d’implémenta- 
tion. Notre version du lisp lexical SCHEME 
a été complètement réécrite, pour être com- 
patible avec le standard défini dans Revised 
(3) Report on the Algorithmic Language 
Scheme. Les valeurs multiples et un impor- 
tant noyau d'outils de mise au point ont été 
ajoutés. Cette version figure sur la liste de 
distribution de SCHEME diffusée par H. 
Abelson au M.LT., et a été demandée par des 
organismes très variés (e.g. CERN, Univer- 
sité d’'Utah). Elle est à l'heure actuelle com- 
mercialisée par la société SODIMA. 

Thierry Porcher a porté SCHEME sur une 
nouvelle architecture de type RISC : KIM 
développé par SODIMA. 


Progroammeatier 
d’architectures 
parallèles synchrones 


Ces études sont menées en collaboration 
avec la société NCR, avec laquelle Patrick 
Sinz a organisé un concours national de pro- 
jets, qui a permis la diffusion de machines à 
bases de multi-processeurs Gapp dans les 
laboratoires nationaux. . 

Nous nous sommes consacrés à la mise au 
point d’un langage de programmation de 
cette architecture nommé Gap} variante 
parallèle de SCHEME, à la construction d’un 
répertoire d’algorithmes de base, développé 
par Marie-Noelle Rozin sous le nom de pro- 
grammation plane, et à l'adjonction d’une 
architecture de routage pour les communi- 
cations non-locales. 


Nouvelles Architectures 
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Roger Tanguy, assisté de Didier Sagot et 
Roland Ballesta, ont construit en 1987 une 
machine en tranches AMD 29300, à 100 nano- 
secondes de temps de cycle, pour le contrôle 
d’une grille de 288 processeurs élémentaires 
Gapp. 

Un autre ensemble d’études est mené en col- 
laboration avec l’Institut d’Électronique 
Fondamentale d'Orsay (F. Devos), pour la 
réalisation de langages et de systèmes d’ex- 
ploitation pour une architecture de machine 
parallèle pyramidale dédiée au traitement 
d'image. 


1. ARCHITECTURE DE ROUTAGE POUR 
MACHINES SIMD 


Jacqueline Signorini a réalisé une architec- 
ture de routage pour le chip multiprocesseur 
Gapp NCR 45CG72. 

Le réseau de routage de type hypercube et 
constitué de 16 routeurs, confère à la 
machine de base Gapp SIMD bit-série deux 
capacités nouvelles : 1) la communication 
non-locale entre processeurs-éléments non 
voisins, 2) la transmission de messages dont 
la taille est fixée à 64 bits. Cette réalisation à 
donné lieu à publication à LE.E.E. AT88, à 
Hitachi City, Japon. 

Signorini a défini et implanté un jeu de 
micro-instructions qui, ajusté aux 13 lignes 
de contrôle de la machine SIMD, permet la 
programmation des nœuds-routeurs du 
réseau. Le contrôleur multiplexe l’un et 
l’autre jeu de micro-instructions en fonction 
de la valeur d’entrée d’une broche supplé- 
mentaire du chip. 

Des configurations partielles de la grille des 
processeurs-éléments (arbres, anneaux, gra- 
phes quelconques) sont désormais possibles 
grâce à la programmation par routeurs. 
L'architecture Gapp-Routeur est simulée en 
langage C sous Unix. Les applications sui- 
vantes ont été micro-programmées : som- 
mation d’arbres, H-tree, anneau de proces- 
seurs, réseau sémantique, pour illustrer dif- 
férents aspects de la programmation paral- 
lèle d'éléments de traitement. 


2. PROGRAMMATION 
D’ARCHITECTURES PYRAMIDALES 
Jean Méhat développe la partie logicielle du 
projet de machine parallèle de structure 
pyramidale Sphynx construite à l’Institut 
d'Électronique Fondamentale d'Orsay. 


Méhat travaille sur le contrôle et la program- 
mation des machines pyramidales Muiti- 
SIMD. Le contrôle pose un problème d’archi- 
tecture à cause 1) du volume des flux d’ins- 
tructions vers les couches de processeurs, de 
ordre du Giga-bits par seconde, 2) de la 
nécessité de les synchroniser entre eux, en 
raison de l'aspect MIMD entre les couches. 
Il a développé un modèle de contrôle, basé 
sur la division des processus suivant la classe 
de mouvements de données auxquels ils 
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prennent part (ascendant vers le sommet où 
descendant vers la base) suffisamment puis- 
sant pour permettre des mouvements de 
données variés (e.g. croisements) et suffi- 
samment simple pour donner un débit d’ins- 
truction tenant les processeurs occupés. 


À. cet effet, il a développé un langage de pro- 
grammation pour les architectures pyrami- 
dales, Pyr-e, qui adresse les deux aspects 
SIMD et MIMD. Il est construit comme une 
extension du langage C. 


L'aspect SIMD esttraité par l’adjonction au C 
d’un domaine, parallèle ou sériel, qui spécifie 
si une variable est traitée dans l'ordinateur 
hôte ou dans les processeurs élémentaires 
d’une couche, Le domaine est spécifié au 
moment de la déclaration des variables et le 
domaine des expressions est déduit de celui 
des variables qui la composent. Si néces- 
saire, des conversions de domaines sont 
effectuées. 


De même, le domaine des structures de con- 
trôle est déduit de celui de leurs expressions 
de test, Les structures de contrôles du 
domaine parallèle sont traduites par des 
manipulations de l’ensemble des proces- 
séurs qui exécutent les instructions, Cette 
programmation, au niveau des processeurs, 
permet une grande souplesse de la program- 
mation, 


L'aspect MIMD est traité par les ransmis- 
sions de contrôle : les activités dans une 
couche sont initialisées par celles des cou- 
ches voisines. De cette façon, des processus 
locaux sont créés et disparaissent au fur et à 
mesure de la progression des mouvements 
de données. Les contrôleurs de couche per- 
mettent d’éviter les collisions entre mouve- 
ments de données. 


Le compilateur Pyr-e a été développé sous 
Unix; il produit du code pour la machine 
pyramidale Sphynx réalisée à l’LE.F. 


3. NOUVELLES PERSPECTIVES 
L'équipe examine depuis peu les perspecti- 
ves d’architectures ouvertes par l'approche 
connexionniste : La thèse de Christophe 
Lecerf soutenue en 1987, développe des 
méthodes d’auto-apprentissage et d’auto- 
organisation pour des réseaux d’automates 
neuronaux. 

Jacqueline Signorini travaille à présent sur la 
construction d’un système de CAO pour la 
programmation d’automates cellulaires à 
très grande échelle. 
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Département d'Informatique 
Université Paris 8-Vincennes 
2, rue de la Liberté, 93526 Saint-Denis 
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LITE 


2, place Jussieu, 75221 Paris 


& (1 43362525 
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Nouvelles architectures & langages pour l’intelligence artificielle 


Classifications de 
concepts par graphes 
de partitions 


La programmation parallèle pour l’intelli- 
gence artificielle et la représentation des 
connaissances suppose la maîtrise de la pro- 
pagation de messages dans des topologies 
pouvant être arbitrairement complexes. 


Daniel Goossens travaille actuellement sur 
l'intégration dans des systèmes de déduction 
automatique d’une opération de classifica- 
tion de concepts, basée sur une structure de 
données appelée graphe de partitions. Cette 
opération doit jouer un rôle complémentaire 
à l'opération d’unification en logique des pré- 
dicats. Elle prend en charge le processus 
essentiel et à long terme de comparaison de 
toute expression formelle nouvellement 
construite, avec les anciennes, La vérifica- 
tion d’une solution d’un exemplaire de cette 
opération est un problème co-NP complet. 


En juillet 1986, il a soumis à J'E.C.A.L. (Euro- 
pean Conference on Artificial Intelligence) une 
première version complète de cette opéra- 
tion. Depuis, il a développé, implémenté et 
justifié théoriquement une série de straté- 
gies de propagation de relations booléennes 
entre concepts dans les graphes de partitions. 


Ces stratégies constituent des implémenta- 
tions incomplètes de cette opération, et cal- 
culables en temps polynomial, ce qui en fait 
des outils de déduction fondamentaux utili- 
sables en pratique. 


Ces implémentations incomplètes s’inscri- 
vent dans le cadre de l'étude systématique 
des graphes de partitions introduite par L.K. 
Schubert. Leur intégration danses systèmes 
de déduction automatique est à mettre en 
parallèle avec les tentatives d’exploitation 
des connecteurs booléens dans les formules 
logiques, par exemple sous forme de règles 
de réécriture et d’unifieurs ACI comme il est 
fait chez J. Hsiang, et avec association de 
types structurés en treillis booléens, aux 
variables logiques, comme l’illustrent les tra- 
vaux de A.G. Cohn. Un des buts de cette 
interprétation, la classification automatique 
d'expressions formelles; est illustré en ana- 
lyse syntaxique du langage naturel par le 
classifieur de règles de grammaire du lan- 
gage de représentation de connaissance KL- 
ONE réalisé par Schmolze et Lipkis. La base 
théorique provient en partie de l’explicita- 
tion par J.C. Reynolds de la structure de 
demi-treillis de l’ensemble des termes du 
premier ordre muni de l'opération d’unifica- 
tion. 


La restriction des stratégies de propagation à 
des stratégies polynomiales participe à l’ex- 
ploration systématique des stratégies poly- 
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nomiales de calcul de relations de subsump- 
tion entre expressions formelles en général, 
introduite par R.J. Brachman et H.J. Leves- 
que. 


Parallèlement, Goossens a implémenté en C 
sur Maclntosh une bibliothèque de primiti- 
ves d'édition interactive de graphes à partir 
de laquelle il a entre autres implémenté un 
éditeur interactif de graphes de partitions. 


Environnements 
de programmation : 
bVLISP 


L'étude des environnements de program- 
mation est devenue un important domaine 
de recherche qui complète et prolonge la 
conception de langages : on peut mention- 
ner l’ensemble des travaux effectués à 
Brown University, et ceux menés par N. 
Habermann à l’Université de Carnegie-Mel- 
lon. 

Harald Wertz a conçu l’environnement de 
programmation bVLISP qui a permis de 
mettre au point une méthodologie d’implé- 
mentation fondée sur les concepts d’attaches 
et d'assertions. 


Ce système a donné lieu à de nombreuses 
publications décrivant ses capacités d’édi- 
tion, de documentation, et d’aide à la mise 
au point. Les travaux récents ont permis une 
clarification et une simplification des primi- 
tives d’implémentation de tels systèmes. 

bVLISP a été développé initialement en 
VLISP, le système LISP à liaison dynamique 
conçu par P. Greussay. Ses diverses capaci- 
tés d’aide à la lecture, à l'observation et à la 
modification de programmes LISP sont dues 


à deux modifications de l'interprète LISP : 


1) une représentation de Histes permettant 
Pattache d'informations supplémentaires 
aux champs usuels, 2) un nouveau noyau 
d’interprète (eval, apply, liaïson-déliaison de 
paramètres) capable. de prendre en compte la 
présence d’attaches. 


Le module eval permet le lancement d’acti- 
vités attachées à des points arbitraires des 
programmes à évaluer : évaluation d’activi- 
tés d'observation ou de vérification asso- 
ciées à des fonctions standard. 

Le module apply donne des capacités corres- 
pondantes pour les fonctions définies par 
Putilisateur, 

Enfin le module de liaison-déliaison permet 
l'évaluation d'activités d’observations ou de 
vérifications attachées à des variables, 


Dans les systèmes LISP à liaison dynamique, 
ces capacités étaient en germe dans les cons- 
tructions telles que evalhook et applyhook, 
C’estlors d’une adaptation expérimentale de 
bVLISP à SCHEME que Wertz a mis au point 
une nouvelle construction : bind-unbind- 
hook. Il semble que ces trois constructions 
soient suffisantes pour le portage de la tota- 
lité de l’environnement bVLISP à un LISP à 
liaison lexicale tel que SCHEME ou COMMON- 
LISP, 


La structure d’implémentation d’environne- 
ment de programmation ainsi dégagée peut 
se transposer à des langages très différents de 
LISP : l’équipe analyse actuellement les pos- 
sibilités de modifications d’un interprète 
PROLOG pour y adjoindre les trois construc- 
tions de base, On peut en espérer rapide- 
ment une version de PROLOG comportant 
l'édition et la maintenance de versions de 
programmes, des outils de trace, d’observa- 
tion et de vérification, ainsi qu’un module de 
documentation automatique et incrémen- 
tale de programmes PROLOG. 


Collaborations 
industrielles, contacts 
internationaux 

Depuis un an, Harald Wertz, Vincent Les- 
bros et Philippe Krief collaborent avec la 
société Thompson pour la construction d’un 
système interactif et graphique de spécifica- 
tions de projets. 


Cette étude est soumise à la CEE, pour 
devenir un projet Esprit, en collaboration 
avec DELPHI (Italie), la Politechica de Milan 
(talie), Xerox (France), l’université de Dort- 
mund (RFA) et la société PCS (RFA). Dans ce 
projet les techniques d'évaluation symboli- 
que et de représentations multiples de pro- 
grammes mises au point par l’équipe seront 
intensivement utilisées. 
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[Ridoux 86] O. Ridoux, “La gestion de 
mémoire temps réel des langages de 
programmation relatiannels’, Thèse 3° cycle, 
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[Chevallier 87] L. Chevalier, S. Le Huitouze, 
©. Ridoux, “Style de programmation pour une 
machine de programmation logique munie 
d'un récupérateur de mémoire’, Séminaire 
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19-21 mai 1987. 


[Ridoux 87] ©. Ridoux, “Deterministic and 
Stochastic Modeling of Parallel Garbage 
Collection - Towards Real-Time Criteria', 
14th Symposium on Computer Architecture, 
Pittsburgh, Pennsylvanie, 2-5 juin 1987. 





de la logique 


Le thème central du projet est la réalisation 
d’interprètes et de compilateurs de langages 
basés sur la logique des prédicats dont Pro- 
log est le représentant le plus connu. Nous 
nous attachons à trouver une solution effi- 
cace aux problèmes spécifiques de gestion 
de mémoire posés par ces langages. 

Notre objectif principal est de fournir aux 
concepteurs de tels langages des mémoires 
tant matérielles que logicielles, possédant 
une récupération automatique et qui soient 
aptes à être employées dans toute nouvelle 
mise en œuvre de compilateur ou d’inter- 
prète. 

Concernant les caractéristiques des mises en 
œuvre que nous offrons, nous avons deux 
soucis principaux qui sont l'efficacité du 
point de vue mémoire et la largeur de leur 
spectre d'utilisation. De plus, nous respec- 
tons une contrainte importante de concep- 
tion : dans les produits que nous déve- 
loppons, la récupération de mémoire doit 
pouvoir être effectuée en parallèle ou en 
semi-parallèle avec l'interprétation. Pour la 
récupération en parallèle, nous sommes évi- 
demment amenés à développer du matériel 
spécifique. En particulier, c’est ce qui a été 
fait pour les microcalculateurs compatibles 
IBM PC pour lequel nous avons développé 
une carte mémoire comportant un COproces- 
seur microprogrammable incorporé sur la 
carte qui se charge de la récupération en 
parallèle de l'interprétation. 


Notre activité est orientée dans trois direc- 
tions : 

e spécification d’une machine abstraite in- 
termédiaire appelée MALI, qui offre des pos- 
sibilités de création, modification, conserva- 
tion d’objets structurés de haut niveau aptes 
à représenter l’état d’un interprète ; 

s réalisation de diverses implantations de 
MALI, 

e réalisation d'’interprètes Prolog utilisant 
MALL 


Les paragraphes qui suivent traduisent ces 
trois types d’activités, 


Conception de MALI 


Afin de pouvoir supporter Prolog Il, le réper- 
toire de commandes de MALI a été entière- 
ment redéfini; il possède toutes les com- 
mandes de l’ancienne version, mais com- 
porte des notions supplémentaires : unifica- 
tion de termes rationnels, variables à attribut 
(pour les coroutines de Prolog Il), gestion 
interne à MALI du parcours de termes ration- 
nels, création incrémentale de termes, possi- 
bilité de détruire un intervalle de points de 
choix au sein de la pile des choix (coupure de 
“tronçons”). 


Mise en œuvre des langages 


Le fonctionnement interne de cette nouvelle 
version de MALI a été spécifiée en langage de 
haut niveau : cette spécification sert de base 
à la microprogrammation manuelle de la 
carte MALI pour IBM PC (voir paragraphe 
suivant). 


Implantation 
matérielle de MALI 
CARTE MALI POUR IBM PC 

La carte MALI au format PC (voir rapport 
d’activité 86) a été mise au point; elle peut 
être insérée aussi bien dans un PC-XT que 
dans un PC-AT, le choix se faisant par quel- 
ques “straps” sur la carte. Pour valider le bon 
fonctionnement de la carte, nous l'avons uti- 
lisée avec notre précédent système Prolog 
expérimental. Actuellement, la nouvelle 
version de microprogramme MALI est en 
cours de programmation d’après notre spéci- 
fication en langage de haut niveau, Cetravail 
est effectué avec la collaboration d’un ingé- 
nieur de la société CRIL; cette version 
devrait être au point en décembre 87. 
Nous avons été amené à écrire un système 
de mise au point et de test du microcode : ce 
système de mise au point a été rédigé en Pro- 
log II augmenté de quelques prédicats éva- 
luables pour dialoguer avec la carte MALI 
installée sur le PC; le Prolog II utilisé est 
notre propre version de Prolog II bâtie sur 
une version logicielle de MALI. 

Enfin, nous commençons actuellement le 
transport de notre Prolog II sur la nouvelle 
version matérielle de MALI. L'interface de 
notre Prolog JI avec MALI a été conçue de 
telle façon que son accrochage à la version 
matérielle de MALI soit relativement sim- 
ple : le transport consiste en une redéfinition 
de macros C. Ce transport est en cours et 
devrait être terminé pour la fin de l’année 87; 
nous aurons alors un système Prolog II fonc- 
tionnant avec une version matérielle de 
MALI sur IBM PC (système MS-DOS), offrant 
une récupération de mémoire en temps réel. 


RÉALISATION D'UN CIRCUIT VLSIAPTE 
A LA MICROPROGRAMMATION DE 
MAL 

Grâce à une aide financière du CNET, nous 
avons pu continuer cette année la concep- 
tion d’un circuit intégré CMOS pour la réali- 
sation d’une nouvelle carte MALI. Deux cir- 
cuits ont été dessinés au début de l’année. 
Leur cuisson a été confiée au CMP. Le CNET 
de Grenoble a reçu le premier (CMOS un 
métal) qui rassemble divers motifs de test. 
La société MHS s’est occupée du deuxième 
circuit (CMOS double métallisation) qui 
implémente une mémoire à double accès 
avec arbitre intégré. Le test fonctionnel du 
premier circuit, déjà réceptionné, reste à 
faire. Le deuxième circuit n’est pas encore 
arrivé, 
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Responsable scientifique 
Y. Bekkers 


Parallèlement à cette activité de réalisation 
de bas niveau dont le but est la familiarisa- 
tion avec la technologie des circuits intégrés 
CMOS, la conception du circuit se poursuit, 
La prise en considération de la position parti- 
culière occupée par le circuit intégré dans 
larchitecture globale : 

° coprocesseur au service de l’hôte, 

e processeur autonome pour son activité de 
gestion mémoire, 

et l’importance des interfaces pour ce circuit 
(avec lhôte, avec la mémoire des termes) 
nous ont orientés vers certaines solutions 
concernant le cadencement du circuit et son 
architecture, 


La définition des unités fonctionnelles cons- 
tituant la machine MALI et le dessin de la 
frontière qui isle le circuit intégré du reste de 
la carte ont été effectués. Le brochage du cir- 
cuit s’en est trouvé ébauché, il reste à le pré- 
ciser : un bus de 32 bits avec adresses et don- 
nées multiplexées permet d’accéder à la 
mémoire des termes et à la mémoire com- 
mune, un bus de 16 bits lui aussi multiplexé 
relie le circuit à sa mémoire de microcode, 
L'architecture interne du cireuit au niveau 
registre est en train d’être spécifiée à l’aide 
du simulateur logique HILO (système de 
simulation de circuits logiques) ; le jeu d’ins- 
truction du processeur dont le point de 
départ est celui de la maquette déjà existante 
est lui aussi en chantier. 

Une stratégie de cadencement particulière 
dite “autosynchronisée”, par opposition au 
cadencement synchrone, a été choisie. Un 
simulateur adapté à la modélisation de ce 
genre de machine a été écrit pour valider les 
interconnections intra-modules du circuit. 


Implantation 

logicielle de MALI 

en “€ 

L’implantation logicielle de MALI réalisée 
sur IBM PC l’année passée a été transportée 
cette année sur machines UNIX, en particu- 
lier sur SUN et HP 9000 UNIX. Un autre trans- 
porta été effectué sur VAX 750 et a été intégré 
au logiciel Prolog/P. 

L’effort sur cette version logicielle de MALI a 
aussi porté sur sa documentation afin d’en 
faciliter sa diffusion. Un document complet 
est en cours de rédaction. 

Les performances en vitesse sur IBM PC de 
cette version logicielle de MALI nous ont 
agréablement surpris puisque cette version 
de MALI a permis la mise en œuvre d’un 
interprète Prolog II deux à trois fois plus 
rapide sur la même machine que Pinterprète 
Prolog II original commercialisé par la so- 
ciété Prolog IA. 


Organisme 

INRIA - Rocquencourt 
Domaine de Voluceau 
Rocquencourt 

78150 Le Chesnay 

& (1) 3963551 


Université de Rennes 


Réalisation 
d'interprètes Prolog 


RÉALISATION D'UN INTERPRÈTE PRO- 
LOG IF 


L’interprète Prolog II/MALI, commencé 
Pannée dernière, a été enrichi par ladjonc- 
tion de nombreux prédicats évaluables. Le 
logiciel est maintenant entièrement compa- 
tible avec le Prolog I de Prolog IA. L’indexa- 
tion des clauses est une technique générale- 
ment réservée aux compilateurs Prolog à la 
seule fin d'améliorer les performances en 
temps d'exécution. Nous avons rajoutée à 
notre interprète pour deux raisons. Premiè- 
rement, l’unification de certaines têtes de 
clauses est purement et simplement suppri- 
mée car on détecte qu’elle échouerait de 
toute façon. Ceci a un effet direct sur la 
vitesse d'exécution. La deuxième raison est 
une raison plus logique. Le fait de supprimer 
certaines unifications diminue le non-déter- 
minisme et donc le nombre de points de 
choix sauvegardés lors d’une résolution, 
Outre le gain de temps provoqué par l’ab- 
sence de commandes de sauvegarde, le vo- 
lume d’informations dynamiques nécessai- 
res est réduit, ce qui entraîne une meilleure 
utilisation de la mémoire de MALI. 

Les mesures effectuées (voir plus haut) ont 
Hope que Prolog I/MALI se comporte 

jen. 


Actuellement, deux transports de cette ver- 
sion sont en cours : 

e une version sur IBM PC utilisant la carte 
MALI, 

e une version sur SUN. 


RÉALISATION D'UN INTERPRÈTE 
PROLOG/P 


Un ingénieur de la CRIL (voir actions indus- 
trielles) a été accueilli à PIRISA dans le but de 
le former aux techniques de mise en œuvre 
des langages de programmation logique, et 
particulièrement aux principes de gestion de 
mémoire conçus dans l’équipe (la machine 
abstraite MALD), et de diffuser ces techni- 
ques auprès d’un éventuel partenaire indus- 


triel, 

Une partie de cette formation a consisté en la 
réalisation d’un système Prolog compatible 
avec celui que la CRIL distribue (Prolog/P). 
Pour ce transport, une partie du système Pro- 
log/P à été récupérée. En effet, nous avons 
conservé l’analyseur syntaxique, le généra- 
teur de la représentation interne des pro- 
grammes et les interfaces utilisateur et sys- 
tème du produit final écrit en Pascal. Nous y 
avons greffé un nouvel interprète, de nou- 
velles procédures d'évaluation des prédicats 
évaluables et bien entendu la mémoire 
MALI elle-même, le tout est écrit en C. 


Participants 
B. Canet 

©. Ridoux 

L. Ungaro 

L, Chevallier 

$. Le Huitouze 
M. Amraoui 

H. Lacourt “ 


Étude des problèmes 
de compilation 
en relation avec MALI 


COMPILATION DE PROLOG 

Cette année, nous avons démarré l’étude de 
Ja compilation de Prolog et l'influence sur 
celle-ci des techniques de gestion de 
mémoire, Nous avons considéré deux tech- 
niques : la technique procédurale de War- 
ren, qui induit la machine abstraite de War- 
ren (WAM), et la machine MALI, qui spécifie 
sa propre gestion de mémoire et sert de 
machine cible à la compilation. Les deux 
manières de compiler sont très différentes 
pour tout ce qui met en jeu la gestion de 
mémoire. Toutefois, une approche descen- 
dante met en évidence un niveau de détail où 
les deux manières sont indifférenciées. En 
ce qui concerne la généralisation des deux 
manières de compiler à des stratégies d’éva- 
luations nouvelles, on constate à nouveau 
d'importantes différences. 

La machine WAM, parce qu’elle est fondée 
sur une technique de gestion de mémoire 
procédurale où la pile des appels est l’élé- 
ment principal, ne peut pas servir à l’inter- 
prétation efficace d’un langage de program- 
mation logique où la stratégie d'évaluation 
ne serait plus séquentielle (ex. de gauche à 
droite) mais concurrente, La machine MALI 
étant indépendante de la stratégie d’évalua- 
tion conserve ses capacités quelle que soit la 
stratégie, 

Actuellement, nous nous engageons au côté 
de la société CRIL dans une phase de déve- 
loppement d’un compilateur industriel utili- 
sant MALI (voir paragraphe actions indus- 
trielles). 


UNE EXPÉRIENCE DE COMPILATION 
DE PROLOG II SUR MALI 

Nous avons réalisé un compilateur expéri- 
mental de Prolog H, qui utilise la version 
logicielle de MALI. Ce compilateur est basé 
sur la définition d’un ensemble de pseudo- 
instructions d’une machine abstraite. L’im- 
plémentation consiste à coder ces pseudo- 
instructions par des commandes MALI. Le 
code généré par Le compilateur est un pro- 
gramme “C” qu'il faut recompiler à son tour 
puis lier au système MALI. Le compilateur 
est écrit en Prolog. 

Cette réalisation a été menée dans une pers- 
pective d'intégration avec l'interprète Prolog 
Il existant, ce qui a nécessité l’utitisation des 
mêmes structures de données et des mêmes 
stratégies de réalisation des prédicats prédé- 
finis tels que le “Dif” et le “Geler”, etc. 
Cette réalisation a été conçue en dehors de 
tout souci d’efficacité dans un but didactique 
afin de mieux mesurer les problèmes d’inté- 
gration d’un compilateur et de la machine 
MALI. Une thèse de M. AMRAOUI présente 
le bilan de cette expérience, 
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Mise en œuvre des langages de la logique 


Actions industrielles 


Actuellement, notre équipe a des relations 
privilégiées avec le centre de Rennes de la 
société CRIL. Cette année, nous avons pu 
former un ingénieur de cette société aux 
techniques de gestion de mémoire dans les 
interprètes Prolog, en particulier à l’utilisa- 
tion de MALI. En effet, grâce à un contrat tri- 
partite entre cette société, l’IRISA et l’EPR, 
un ingénieur de cette société a pu passer six 
mois dans notre équipe. Durant les quatre 
premiers mois, nous avons effectué en com- 
mun le transport de l’interprète Prolog/P de 
la CRIL sur MALI. Les deux derniers mois 
ont été consacrés à une préétude des problè- 
mes de compilation de Prolog. 

Ce travail débouche maintenant vers des 
perspectives industrielles pour notre équipe 
puisque la société CRIL s'engage actuelle- 
ment dans le développement d’un compila- 
teur Prolog utilisant MALI. Nous comptons 
participer activement à ce développement en 
fournissant une mémoire MALI logicielle 
adaptée au compilateur de la CRIL. 

Un deuxième ingénieur de la CRIL, récem- 
ment intégré dans notre équipe, est en train 
de se familiariser avec nos réalisations maté- 
rielles. Il participe à la microprogrammation 
de la carte MALI pour IBM PC. Notre objectif 
pour l’année 1988 est de trouver un finance- 
ment pour pouvoir entreprendre, après une 
période de mise au courant, une mise à 
niveau industrielle de notre carte compatible 
PC en vue de sa commercialisation. 














Responsable scientifique 
Marc Gillet 






d'outils Prolo2. 


Organisme 

1B8M/ Centre Scientifique 

36, avenue Raymond-Poincarré 
75016 Paris 

& (1) 45051400 


Présentation 

du thème 

En 1987, le projet “Implémentation et cons- 
truction d’outils Prolog” du Centre Scientifi- 
que IBM comprenait trois activités centrées 
sur Prolog : 

e L'interprétation et la compilation de Pro- 
log (VM/Prolog, Bayou). 

e L'utilisation de langages objets pour la 
représentation des connaissances en Prolog 
(Glances). 

e L'interprétation et la compilation du Con- 
current Prolog. 


Principaux résulrats 
obtenus en 87 


BAYOU 

(Marc Gillet, Xavier de Lamberterie, Gilbert 
Rouquié, Zeina Zein) 

Après la réalisation de VM/Prolog qui était 
une implémentation de Prolog de : 

1. type “structure sharing”, 

2. avec un espace adressable de 24 bits, 

3. composé d’un interpréteur et d’un compi- 
lateur incrémental. 

Une nouvelle implémentation de Prolog 
appelée Bayou a été entreprise. 


Bayou possède les caractéristiques suivan- 
tes : 

1. type “structure copying”, 

2. avec un espace adressable de 31 bits, 

3. composé d’un interpréteur et d’un compi- 
lateur incrémental et d’un compilateur com- 


plet, 

4, possibilité de partager un espace de travail 
Prolog en mémoire centrale entre plusieurs 
utilisateurs. 


A cette date : 

e l’interpréteur et le compilateur incrémen- 
tal sont terminés et testés, 

e les prédicats prédéfinis sont terminés et en 
cours de test, - 

e une interface entre Bayou et les langages : 
assembleur, Fortran, Pascal, PLI a été réali- 
sée, 

e le générateur de code du compilateur com- 
plet est terminé. 


GLANCES 

(Zeina Zein) 

Glances est un langage de représentation des 
connaissances implémenté en VM/Prolog et 
basé sur Les concepts de la Programmation 
Orientée Objet. 


En plus des caractéristiques classiques des 
langages orientés objet, Glances offre la pos- 
sibilité de représenter des objets satisfaisant 
des contraintes. Deux modes de déclenche- 
ment des contraintes sont possibles : auto- 
matique et à la demande de Putilisateur. 

Glances est utilisé comme langage de repré- 


Implémentation et construction 





Participants Remy Picca 
Jacques Bellone Gilbert Rouquié 
Marc Gillet Zeina Zein 
Xavier de Lamberterie 


sentation de la base de connaissances d’un 
système d’“Aide à la Sélection de produits 
bancaires” dans Le cadre d’une étude menée 
conjointement avec une banque. 

Cette année, le travail a porté sur l’achève- 
ment de cette étude : construction d’une 
base de connaissances en grandeur réelle. 
L'approche Prolog-Objets s’est révélée bien 
adaptée pour élaborer et gérer des bases de 
connaissances importantes, 

Les performances actuelles du système sont 
satisfaisantes. Elles sont supérieures à celles 
de nombreux systèmes de schémas, en rai- 
son de la modularité de la base qui rend les 
accès très efficaces. 

De plus, cette architecture permet l’exten- 
sion et la maintenance de la base, tout en gar- 
dant sa cohérence grâce aux mécanismes de 
contrôle. 


IMPLÉMENTATION DE CONCURRENT 
PROLOG 

(Jacques Bellone, Remy Picca) 

s'agissait d'effectuer une implémentation 
de Concurrent Prolog dans le cadre d’une 
thèse de troisième cycle. 

Cette thèse a été soutenue en septembre 87 
et cette soutenance a terminé l’activité du 
projet sur Concurrent Prolog. 


Perspectives futures 
BAYOU 

Le compilateur complet sera terminé en juin 
88 et le restant de l’année sera consacré : 

e au test du compilateur complet, 

e à terminer le ramasse-miettes et à le tester, 
e à réaliser le partage d’espace de travail en 
mémoire entre utilisateurs. 


GLANCES 


L'année 1988 verra le développement d’un 
moteur d’inférence spécifique et d’un 
debugger. 
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Responsable scientifique 
Pierre Casteran 

Cette nouvelle équipe et son projet 
viennent d'être accueillis 

tout récemment au sein du 

Gréco programmation au moment 
de la préparation de cet ouvrage. 


LEXICO MOTS CLES 
Lisp 

programmation logique 
programmation par objets 
Scheme 





Organisme 

Université de Bordeaux | 

UER de Mathématiques et Informatique 
351, cours de la Libération 

33405 Talence Cedex 

5 56846089 & 56846090 


Construction 
d'un Environnement 
de Programmation 


Nous nous proposons de construire un envi- 
ronnement autour d’un compilateur utili- 
sant la conversion en code “CPS” (Continua- 
tion Passing Style) [STEELE, KRANZ et al.]. 
Cette technique consiste en la création d’un 
code intermédiaire, toujours en Scheme ; ce 
code, bien que peu lisible pour un lecteur 
humain, contient toutes les informations 
nécessaires à l'optimisation du code compilé : 
béta-réduction, analyse de fermetures, etc. 

Notre environnement doit pouvoir fournir 
en clair ces informations, afin de permettre 
une analyse de la qualité du code généré. Ces 
outils nous paraissent nécessaires, le langage 
Scheme encourageant plus que tout autre 
Pemploi intensif d’abstractions et de récur- 
sivité. 

Une extension intéressante pourrait être la 
généralisation de ces outils à des schémas de 
programme, afin de raisonner sur des classes 
de programmes plutôt que sur des exemples 
particuliers. 


Applications 
PROGRAMMATION PAR OBJETS 


Scheme a été choisi pour être le langage de 
commande du projet LUMIÈRE du Labora- 
toire d’Informatique de l’Université de Bor- 
deaux I. Ce projet consiste en la réalisation 
d’un logiciel de synthèse et de manipulation 
d'images réalistes en deux dimensions. 
Une adaptation d'OBJVLISP a été écrite en 
PCScheme, permettant notamment l’usage 
d’objets décrits sous plusieurs aspects, 

La présence de ces multiples aspects soulève 
de nombreux problèmes : 

e équivalence d’aspects, 

s choix d’une représentation réelle ou vir- 
tuelle, 

e héritages, 

Dans le cadre plus précis de la synthèse 
d'images 2D, des expériences concluantes 
ont porté sur la structuration des couleurs et 
des régions, et la spécification de dégradés. 


PROGRAMMATION LOGIQUE 

Nous nous proposons d'étudier deux modè- 
les d'intégration avec Prolog : 

+ les continuations logiques [Haines], 

eles continuations de succès [utilisées 
notamment dans le Prolog Symbolics]. 
Nous pensons que le choix d’un noyau basé 
sur les continuations doit faciliter l'étude de 
ces communications Lisp-Prolog. 


Programmation en Scheme 
et dans les Lisp léxicaux 


Participants Plusieurs étudiants 
Jean-Pierre Braquelaire en DEA et en thèse 
Myriam de Sainte-Catherine seront également 
Jean-Claude Royer associés à ce projet. 
Robert Strandh 


État actuel de ces 
Recherches 


a) Réalisation d’une première maquette 
d'interprète Scheme en LE-LISP, par P. Cas- 
téran. Elle comprend la conversion en code 
CPS, et un interprète spécialisé dans ce code. 
Ce logiciel est utilisé dans les cours de troi- 
sième cycle sur Scheme (DEA et DESS). 

b) Début (janvier 1988) du transport de ce 
programme sur station Symbolics 3620, l’uti- 
lisation des nombreux outils de cette ma- 
chine (Flavors, outils de représentation de 
graphes) facilite la lecture du code CPS. 

c}) ObjScheme, l’adaptation d’Objvlisp en 
PCScheme, écrite par J.-C. Royer, a servi de 
base à l'écriture d’ITTEN, un logiciel pour le 
traitement informatique de la couleur. Une 
communication (P. Castéran, J.-C. Royer) 
a été soumise à EUROGRAPHICS 1988. 

d) Une maquette de logiciel d'enseignement 
de la musique est en cours de réalisation en 
QbjScheme, sous la direction de Myriam de 
Sainte-Catherine. Elle s’appuie, entre au- 
tres, sur un noyau Prolog/Scheme dévelop- 
pé par Patrice Lacoste et Jean-Luc Gibot- 
Leclerc, étudiants en Thèse du C.N.A.M. 


Relations avec 
d’autres équipes 


VLISP80 (Patrick Greussay). 

Certains des outils développés seront inté- 
grés à la version de Scheme écrite en C par 
Patrick Greussay (sur VAX/780, Silicon-Gra- 
phics fris, Stations Sun). 

METHEOL (Michel Billaud, G. Filé, M. Cor- 
sini). 

La recherche sur l'intégration Scheme-Pro- 
log se fera en collaboration avec cette équi- 
pe, notamment sur les problèmes de para- 
métrisation de la stratégie de recherche et la 
représentation de la liste des succès d’un ap- 
pel Prolog par un flux infini (thèse de Michel 
Billaud). 


Moyens existants 
Serveur GeoCub du Greco Programmation 


à Bordeaux, stations SUN, Silicon Graphics 
IRIS, et Symbolics 3620. 








Responsable scientifique 
lon Filotti 






Calcul symbolique 


Organisme 

LR. Université d'Orsay 
université de Paris Sud 

91405 Orsay 

& (1)69416629 & 69416628 


Présentation 

générale 

Nous nous intéressons principalement à 
Parchitecture logicielle et matérielle des 
langages fonctionnels et des langages pour la 
programmation logique. 

De nouveaux modes de programmation se 
rajoutent depuis quelques années à la pro- 
grammation fonctionnelle, outil de choix de 
l'intelligence artificielle, mais aussi et sur- 
tout modèle fondamental du calcul. Parmi 
ceux-ci, la programmation logique est la 
plus connue. 

Les travaux peuvent être divisés comme 
suit: 

- Lisp et programmation fonctionnelle. 

+ Systèmes d'exploitation. 

+ Programmation logique. 

e Outils de programmation. 


Lisp et 
programmation 
fonctionnelle 


Nous travaillons depuis plusieurs années sur 
les implantations efficaces de Lisp. 

Patrick Amar a réalisé LAL, un interprète 
LISP très efficace écrit en C et donc parfaite- 
ment portable, Ce système a des performan- 
ces supérieures à celles de LeLisp. Cet inter- 
prête est devenu récemment une implanta- 
tion parfaitement compatible avec Franz 
Lisp, Elle est utilisée par l’équipe de pro- 
grammation du L.R.I. dans la réalisation du 
système de spécification de types abstraits 
ASPEGIQUE. LAL est également utilisé par 
l'éditeur WINNIE pour son mécanisme d’ex- 
tension. 


Les travaux sur le coprocesseur micropro- 
grammable KOALA sont terminés, Karim 
Hebbar a effectué les tests de Gabriel qui 
confirment nos thèses initiales sur l'intérêt 
de tels coprocesseurs, Nous disposons donc 
d’une machine Lisp à faible coût, réalisée 
intégralement au L.R.I. 

La machine KOALA a été présentée à plu- 
sieurs manifestations importantes, dont la 
plus récente est celle organisée par la 
D.RET. sur les machines symboliques en 
Décembre 1987, 


Systèmes 
d'exploitation 

Les travaux sur une nouvelle génération de 
système d'exploitation sur des multiproces- 
seurs ont été poursuivis, Une première ver- 
sion d’un noyau modifié d’Ünix BSD 4.2, 
avec processus légers a été réalisée par Eric 
Durocher sur la machine PANDA multipro- 
cesseurs construite par l’équipe. 


et nouvelles architectures 


pese) 





Participants Marc Durocher 
Patrick Amar Jon Filotti 
Jean-Paul Bodeveix Karim Hebbar 


Éric Durocher Wladimir Mercouroff 


Progroammneti@on 
logique 

Jean-Paul Bodeveix continue ses travaux de 
réalisation d’un compilateur Prolog parallèle 
sur une structure multiprocesseurs à base de 
Transputers. Une première version du com- 
pilateur a été terminée sur un réseau de 
machines SUN. Il existe deux variantes du 
compilateur : l’une utilisant des processus 
synchronisés par messages, l’autre à parallé- 
lisme ET et variables partagées. 


Outils 
de programmation 


Patrick Amar a réalisé XW, un nouvel éditeur 
de fichiers pour postes de travail graphiques, 
utilisant le système de fenêtrage X-Window. 


L'éditeur fonctionne en mode serveur, Les 
processus clients ouvrent de véritables fenê- 
tres du système x, dans lesquelles ils ont la 
possibilité d'éditer soit en utilisant les tou- 
ches de Péditeur wi, soit la souris et des 
menus. 

Le fonctionnement en mode graphique et 
en mode serveur offre une meilleure ergo- 
nomie. 
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84 
Étude d’Algorithmes sur les 
mots et les codes. 

86 

Analyse d'Algorithmes. 

87 

PANDORE : Un système 
expert pour l'optimisation 
des systèmes dynamiques. 





ONALD JUDD 
STACK”} 1972 (projeté en 1965, réalisé en 1972), MÉTAL, DIX BOÎTES, 
4X 103 x 80 cm chacune. & 

(AM, CENTRE GEORGES-PO, 
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L'algorithmique est une discipline 
ancienne dont on peut faire remon- 
ter les premiers développements à 
l'Antiquité. Elle s'est longtemps inté- 
ressée aux calculs sur les nombres 
eniers et réels, et aux constructions 
de figures géométriques. Depuis 
l'avènement des ordinateurs, et leur 
très large diffusion, d'autres con- 
cepts ont fait leur apparition comme objets possibles 
d'un algorithme ; il s'agit par exemple des fichiers, des 
textes, des réseaux ou de schémas diverstirés de problè- 
mes concrets. La discipline algorithmique s'est alors dé- 
veloppée suivant deux axes : le premier consiste en la 
mise en évidence de structures de base fondamentales à 
l'aide desquelles se décrivent des algorithmes élaborés 
pour des domaines les plus divers ; le second consiste en 
la définition quantitative de la complexité d'un algorith- 
me et la dassification des algorithmes suivant leur com- 
plexité. 

Depuis la création du GRECO Programmation, les pro- 
jets en Algorithmique se sont développés en s'inscrivant 
dans le cadre de ces problématiques. De nombreuxtra- 
vaux ont montré que les notions de 
mots, d'arbres et de graphes jouent 
le rôle fondamental d'éléments de 
base dans le jeu de construction 
constitué par la conception d'algo- 
rithmes. Dans ce cadre, au sein du 
projet Algomots, a été développé 
un logiciel mettant en œuvre des 


algorithmes sophistiqués sur les 





automates et les mots, Ce logiciel 
intéresse à la fois l'informatique 
théorique et de nombreux autres 
domaines comme le traitement de 
textes en linguistique, le développe- 
ment de nouveaux langages de 
programmation logique, ou d'au- 
tres domaines d'applications utili- 
sant les automates. Dans la même 
voie, les algorithmes sur les graphes et leur dessin sur 
écran ont fait l'objet du projet LEG au sein duquel a été 
développé un langage de manipulation d'ensembles et 
de graphes. 
Les axes de développement les plus récents de l'algorith- 
mique montrent son universalité et son rôle de discipline 
fondamentale servant d'outil aux autres branches de 
l'informatique. Îl en est ainsi pour les questions soulevées 
par des problèmes issus des bases de données, des pro- 
tocoles de communication et même de certains aspects 
de l'intelligence artificielle. 
Une place à part doit être donnée à tout ce qui concerne 
l'algorithmique géométrique. Son développement ré- 
cent est spectaculaire ; il est lié à la diffusion du matériel 
graphique : le dessin de figures geé- 
métriques sur écran conduit tout na- 
turellement à se poser des questions 
nouvelles. Toute une partie du pro- 
jet Algo à l'École Normale Supé- 
rieure est orientée dans cette pro- 
blématique et de nombreux nou- 
veaux projets sont en cours de ges- 
tation. Robert Cori 
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Responsable scientifique 
J-M,. Steyaert 


ALGO MOTS CLES 

algorithmes de tri 

analyse d’algorithmes 

calcul formel 

manipulation symbolique d'expressions 
recherche arborescente 





1-M,. Steyaert et R, Casas, "Boftom-up 
recursion in trees", Proceedings of CAAP (Nice, 
1986, Lectures Notes in Computer Science 
n°214, Springer Verlag. 


P. Flajolet et J-M. Steyaert, "À Complexity 
Calculus for Recursive Tree Algorithms", Math. 
Systems Theory 19, 301-331 (1987), 


P. Hennequin; “Combinatorial Analysis of 
Quicksort Algorithm", à paraître dans RAIRO. 


B. Salvy, “Détermination automatique du 
comportement asymptofique des coefficients de 
fonctions génératrices’, Rapport d'Option 
Scientifique, École Polytechnique. 





J-M,. Steyaert : Amiens (mai 1986), Journées 
du PRC Math-info (février 1986), Journées 
Codage et Complexité (CIRM, mars 1986). 


UPC Barcelone (mai 1986). TUW Vienne 
{décembre 1986). 

Journées Groplan du Greco de 
Programmation (novembre 1987). 


Universidad Complutense et Universidad 
Politechnica de Madrid (mai 1987). 


Analyse d'Alcorithmes 


Organisme 

Centre de Mathématiques 
de l'École Polytechnique 
Plateau de Palaiseau 
91128 Palaiseau Cedex 
& (1) 60194091 


Ce thème consiste en l’étude combinatoire 
des algorithmes de base de la programma- 
tion. Un phénomène courant est qu’un pro- 
gramme ne se comporte pas de façon uni- 
forme sur les données selon leur complexité 
combinatoire; cette problématique, large- 
ment développée par D.E. Knuth, est à l’ori- 
gine de nombreux travaux sur l’optimisation 
des logiciels et des systèmes informatiques. 


L'équipe travaille sur deux directions princi- 
pales : les algorithmes de manipulation sym- 
bolique d’expressions logiques et algébri- 
ques et les algorithmes de tri et de recherche 
arborescente, Le premier thème est lié à la 
conception des logiciels de calcul formel et 
de déduction logique, le second est un des 
classiques de l’analyse d’algorithmes. L’ob- 
jectif est de développer des méthodes systé- 
matiques d'analyse qui permettent de pré- 
dire quasiment “à vue” ce qu’on peut at- 
tendre du comportement moyen d’un pro- 
gramme. On s’attache donc à définir des 
méthodes de traduction des programmes en 
équations sur des séries qui rendent compte 
mathématiquement du coût des program- 
mes, puis on utilise des propriétés analyti- 
ques des solutions pour obtenir les compor- 
tements asymptotiques cherchés. 


P. Hennequin (boursier de thèse) a ainsi pu 
reprendre et étendre les résultats de R. Sed- 
gewick sur l’analyse de “Quick-Sort”. Il 
obtient une méthode de calcul des moments 
de la distribution des coûts pour un grand 
nombre de variantes de l’algorithme. Les 
résultats obtenus grâce à l’utilisation inten- 
sive du calcul formel permettent d’espérer 
une caractérisation de la distribution limite. 
Il travaille également sur des extensions au 
cas des clés répétées en collaboration avec 
J. Olivos (Université de Santiago du Chili). 


J.-M. Steyaert, tout en dirigeant les travaux 
de P. Hennequin, travaille sur les algorith- 
mes de simplification d’expressions en colla- 
boration avec R. Casas (U.P.C. Barcelone) et 
MI. Fernandez Camacho (U. Complu- 
tense, Madrid), dont il assure de fait la direc- 
tion de thèse. On montre que, sous de ‘très 
larges hypothèses, le coût moyen est linéaire 
alors qu’il est en O(n.log n) dans le pire des 
cas. Comme ces algorithmes sont en général 
très simples, ceci tend à montrer que des 
algorithmes complexes et sophistiqués qui 
assurent la linéarité dans tous les cas sont 
moins efficaces en pratique. 

La nature des calculs et des développements 
symboliques à effectuer se complexifiant 
très rapidement, il semble aujourd’hui fon- 
damental de développer un système de cal- 
cul formel formel qui permette de manipuler 
effectivement les expressions mathémati- 
ques énormes qui sont produites par nos 
méthodes. Ce système devrait être mis en 
œuvre dans le courant de l’année et contri- 
buer à l'étude de programmes encore plus 








Participants 

P. Hennequin 

B. Salvy 

J-M,. Steyaert 

École Polytechnique 

Centre de mathématiques appliquées 


complexes. C’est Bruno Salvy (X84), bour- 
sier de recherche, qui est chargé de dévelop- 
per la partie “Analyse asymptotique” de ce 
système en collaboration avec Paul Zimmer- 
man (X84) qui travaille à l'INRIA sous la 
direction de P. Flajolet. B. Saivy a déjà réalisé 
une maquette de son système ; il faut en fait 
compiler de nombreux résultats parfois très 
fins issus de l’Analyse Complexe, et les inté- 
grer dans un système de calcul formel. Le 
système choisi est Maple (bientôt diffusé par 
PINRIA) en raison de sa relative transpa- 
rence, de sa taille réduite et de son portage 
aisé sur de nombreuses machines Unix. 
L'équipe est associée au sein du groupe 
“Algorithmes” au PRC Mathématiques- 
Informatique et à l'INRIA. Deux coopéra- 
tions internationales (UPC Barcelone et 
TUW Vienne) sont coordonnées par J.-M. 
Steyaert. 

















Responsable scientifique 
J-P. Quadrai 


PANDORE MOTS CLES 

calcul formel 

FORTRAN 

génération de programmes 
génération de rapports 

Macsyma (outil symbolique pour les 
mathématiques) 

optimisation du calcul scientifique 
optimisation de code 

systèmes experts 





THEOSYS, "Commande optimale de Système 
Stochastique RAIRO*, Automatique 84. 


C. Gomez, J-P, Quadrat, À, Sulem, ‘Towards 
an Expert System in Stochastie Control: the 
Hamilton-Jacobi equation Part, LNLC.LS, n° 63, 
Springer-Verlag 1984. 

€. Gomez, J-P. Quadrat, À. Sulem, “Towards 
an Expert System Control: the Local-feedback 
Part, Congrès Rome sur le contrôle 
Stochastique, LN.M. n° 1119, Springer-Verlag 
1985. 


C. Gomez, J.-P, Quadrat, À. Sulem, “Computer 
algebra as a toof for solving optimal control 
problems. Applications of computer algebra', 
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L'objet du projet est de faire une tentative 
d’automatisation de l’ensemble des activités 
à accomplir dans une étude d'optimisation 
de systèmes dynamiques. Traditionnelle- 
ment, seule l’activité purement numérique 
Pétait. 
Il existe de bonnes bibliothèques de pro- 
grammes numériques pour l'optimisation 
dans R°, l'intégration d’équations différen- 
tielles ou aux dérivées partielles, la résolu- 
tion de systèmes linéaires. Ces programmes 
commencent à être intégrés dans des systè- 
mes de taille importante plus ou moins con- 
viviaux. Ils sont en grande majorité écrits en 
Fortran. Plus récemment, on assiste à des 
tentatives pour les interfacer par une couche 
de type expertise. 





Ces systèmes contiennent une grande quan- 
tité d'informations scientifiques exprimées 
dans une syntaxe de très bas niveau. Ces 
choix syntaxiques s’expliquent, dans un 
premier temps, par la vitesse de calcul néces- 
saire puis par linertie du processus de 
programmation. La communauté du calcul 
scientifique est bien sûr consciente de ces 
problèmes, mais la seule tentative des pro- 
fessionnels de l’informatique pour les résou- 
dre a été de proposer de nouveaux langages : 
Algol, Pascal, APL, ADA, dont impact, pour 
de nombreuses raisons, s'est avéré limité : 
soit le compilateur n’est pas disponible, soit 
il est peu performant et le plus souvent ces 
langages rapportent pas de fonctionnalités 
réellement nouvelles, si ce n’est parfois un 
peu plus de clarté syntaxique, De toute 
façon, les gains potentiels ne justifient pas la 
réécriture des programmes existants. 


Par contre, la disponibilité sur 1e marché de 
langages de calcul formel comme Macsyma 
rajoute une nouvelle fonctionnalité utile au 
calcul scientifique, non pas parce que le cal- 
cul formel serait un substitut du calcul 
numérique, il suffit d’avoir pratiqué ces sys- 
tèmes ou le calcul algébrique pour en voir 
très rapidement les limites, mais parce qu’il 
permet d’automatiser une nouvelle couche 
d’activités en amont du calcul numérique 
lui-même, faite le plus souvent manuelle- 
ment : manipulation de formules algébri- 
ques ou de programmes vus comme des 
formules. 


Plus en amont encore, le codage de théorè- 
mes et de connaissances empiriques sur le 
choix de méthodes et d’algorithmes, Les 
aspects interactifs des interfaces homme- 
machine se codent très bien en Prolog dans 
la mesure: où celui-ci a accès aux facilités 
fournies par des langages comme Macsyma 
(entrée et sortie 2D des formules). 


 PANDORE : Un système expert 
pour l'optimisation des systèmes 






Participants 
JP. Chancelier 
C. Gomez 

J-P. Quadrat 
À. Sulem 


En aval, l'édition scientifique et le graphisme 
3D complètent la panoplie. Dans ces deux 
domaines, un langage comme Macsyma 
apporte des éléments de réponse. 


Forts de cette conviction que Macsyma pré- 
sente un réel intérêt, nous nous efforçons 
d’automatiser l’ensemble des tâches que 
doit accomplir l'ingénieur dans une étude du 
type optimisation de système dynamique 
depuis la spécification du problème à résou- 
dre jusqu'à la génération automatique de 
rapports en passant par la génération de pro- 
grammes numériques et leur exploitation. 


La démarche a consisté essentiellement 
après avoir rassemblé un environnement de 
programmation adapté à ce type d’activité : 
Machine Lisp + Macsyma + Oblogis (Pro- 
log) à réaliser les développements suivants : 


e la définition et l'écriture d’un petit compi- 
lateur permettant la génération de FOR- 
TRAN depuis Macsyma. On appelle ce langa- 
ge MACROFORT, 

e la définition et l’écriture d’un autre compi- 
lateur permettant la génération de rapport 
en LATEX à partir de Macsyma appelé 
MACROTEX, 

e le codage en utilisant ces facilités des con- 
naissances du domaine spécifique : Poptimi- 
sation de systèmes dynamiques, 

e l'écriture d’un éditeur spécialisé à l'entrée 
des problèmes du domaine, 

e l'écriture d’un langage de commande per- 
mettant d'interroger le système ou de modifier 
la base de données associée au problème. 


Le système tourne exclusivement pour l’ins- 
tant sur les machines LISP symbolics. Il est 
capable de générer des rapports écrits en 
LATEX résumant une étude complète à par- 
tir de la seule spécification du modèle. 


Une interface avec un système spécialisé au 
calcul numérique BASILE est en cours de 
développement, 


Desutilisations pour la résolution de problè- 
mes réels ont été tentées. Elles montrent à la 
fois l'intérêt d’un tel système et les améliora- 
tions à apporter pour qu’une personne non 
spécialiste du domaine puisse effectivement 
Putiliser. 
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RECHERCHEINDUSTRIE 
une volonté de Coouperer 


La collaboration recherche-entreprise est désormais considérée comme l'un 
des facteurs les plus importants du développement industriel. Pour l'ensemble 
des entreprises d'un secteur très concurrentiel comme celui de l'informatique, 
exigeant un très haut niveau de technicité, marqué de sauts technologiques 
importants et rapides, la recherche devient aujourd'hui une fonction essentielle. 
Depuis quelques années, déjà, de nombreuses structures et procédures, 
s'appuyant sur des organes publics ou privés, ont vu le jour et s'efforcent 
de rapprocher le monde de la recherche et celui des entreprises. 

Le CNRS s’est défini une politique en faveur de la valorisation et du transfert industriel et mène un certain nombre 

d'actions. (Mise en place de la direction de la valorisation et des chargés de mission aux relations industrielles, 

signature de conventions avec de grandes sociétés, création de laboratoires mixtes et de sociétés filiales, etc.) 

Dans le cadre de ces nouvelles missions du CNRS et depuis son élargissement en PRC, le GRECO Programmation s'est 

engagé résolument dans une politique d'ouverture, de dialogue et de coopération avec les milieux professionnels 

(industriels, SSI, grandi utilisateurs) et un certain nombre d'actions qui avaient été lancées dès 1984 vont désormais 

pouvoir s'intensifier grâce à la mise en place au siège à Bordeaux d'une nouvelle 

structure chargée de la valorisation et des actions industrielles. 

L'élargissement des relations avec le monde industriel implique notamment un 

nouvel effort d'information et de diffusion de l'information scientifique ettechnique. 

Ce rapport scientifique constitue une mise à jour du précédent document 

de synthèse ‘Bilan et Perspectives” édité en 1986. Ce dernier, aujourd'hui épuisé, 

largement diffusé auprès de l'ensemble des responsables de sociétés et de 

la communauté scientifique universitaire a fortement contribué à faire connaître 

les activités du GRECO et a permis d'établir de très nombreux contacts. 

Ces contacts ont favorisé des actions de rapprochement et permis de créer 

une synergie nouvelle entre les deux communautés. Des échanges nombreux 

vont pouvoir s'établir dans un nouvel espace de dialogue convivial et 

permanent, Les collaborations pourront alors se développer entre partenaires 1 

qui auront appris à se connaître, à parler le même langage et à se découvrir Mere Mere dar ee Pre 

des intérêts communs. GRECO Programmation 
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Une action originale : RIS 


De récentes enquêtes viennent de révéler 
l'importance de la veille technologique, nou- 
vel enjeu stratégique pour nos industriels. 
Encouragé par cette récente prise de cons- 
cience, le GRECO PROGRAMMATION a mis 
en place une structure d'accueil d’indus- 
triels: RIS (Recherche-Industrie-Services) 
qui constitue une nouvelle structure d’infor- 
mation et de communication avec le monde 
industriel. 

Ces relations nouvelles avec les entreprises 
s’inscrivent dans un cadre contractuel. RIS 
est aussi une convention à laquelle les entre- 
prises peuvent adhérer en acquittant une 
cotisation annuelle (5.000 francs à 50.000 
francs en fonction de leur taille). RIS facilite 
Ja nécessaire coopération des entreprises 
avec le monde de la Recherche en proposant 
un certain nombre de services. 

Veille technologique, formation-recrute- 
ment, conseils-assistance, sont les trois 
volets de l’offre du GRECO PROGRAMMA- 
TION. De nombreux services sont gratuits 
pour les adhérents: participation au cycle 
annuel des conférences, accès à une liste 
d’experts, aux logiciels prototypes en ligne, 
aux réseaux de la recherche et aux publica- 
tions... D’importantes réductions en outre 
sont accordées pour la participation à cer- 
tains stages de formation. 

Enfin, à travers le GRECO PROGRAMMA- 
TION et l’ensemble de ses équipes (une tren- 
taine environ) réparties dans les principaux 
laboratoires publics ou privés nationaux, les 
industriels peuvent établir un contact avec 
toute la communauté scientifique. 

Les premières adhésions sont enregistrées. 
SLIGOS, CR2A, EDF, SFGL, CODAT INFOR- 
MATIQUE sont parmi les principales sociétés 
impliquées dans ce programme. 

Au-delà du désir d’instaurer de nouveaux 
liens entre les deux communautés et de 
transférer des connaissances, il y a l'espoir 
de créer une synergie nouvelle recherche - 
industrie, qui pourrait déboucher sur des col- 
laborations effectives. 


RIS : VEILLE TECHNOLOGIQUE 


Un cycle annuel de conférences (une dizaine 
environ) organisées à Paris présentent l'état 
de l’art dans les domaines avancés couverts 
par les thèmes de recherche du GRECO PRO- 
GRAMMATION. 


Au cours de l’année 87/88, les techniques et 
outils en génie logiciel ont fait l’objet d’un 
effort de promotion tout particulier. 

88/89 sera surtout consacrée aux langages et 
notamment à la programmation par objet, 


Réservées aux personnels des sociétés adhé- 
rentes à RIS, ces conférences acceptent d’au- 
tres participants dans la limite des places 
disponibles. La participation est gratuite, les 
demandes d'invitation sont à transmettre au 
GRECO PROGRAMMATION. 





Conférence Génie Logiciel, 
hôfel Méridien-Montparnasse Paris. 


RIS : ACTIONS DE FORMATION 


Les formations initiales dans lesquelles sont 
impliqués de nombreux chercheurs et ingé- 
nieurs du GRECO PROGRAMMATION (à 
l'Université ou dans les Grandes Ecoles) doi- 
vent trouver leurs prolongements nécessai- 
res dans des actions de formation continue. 


Un certain nombre de stages de formation 
sont annuellement mis en place. La partici- 
pation importante des professionnels aux 
conférences organisées par le GRECO témoi- 
gne de l'intérêt qu’ils portent aux actions de 
veille technologique et révèle les besoins de 
formation dans des domaines avancés pour 
lesquels les concepts, les méthodes et les ou- 
tils n’appartiennent aujourd’hui encore 
qu’au milieu de la recherche. 


Les nombreux contacts développés avec les 
milieux professionnels, notamment les s0- 
ciétés adhérentes à RIS devraient assurer leur 
succès, 


Un soutien financier du FIT (Fonds pour 
l'Innovation Technologique du Ministère de 
la Recherche et de l'Enseignement Supé- 
rieur) va permettre d’organiser dès 88/89 un 
ensemble de formations en informatique 
avancée. 


Les thèmes suivants seront abordés: ADA, 
langage LISP, programmation par objet, 
spécifications formelles, UNIX, métacom- 
pilation, 


De nombreuses entreprises parmi lesquel- 
les: AMAIA, SLIGOS, CR2A, EDF, CGE, 
ORSTOM ont déjà sollicité le GRECO pour 
élaborer avec lui des programmes de forma- 
tion, pour elles-mêmes ou leurs clients, 

La formation, vecteur du transfert industriel 
des connaissances, constitue avant tout un 
moyen privilégié de rapprochement recher- 
che-industrie et devrait susciter de nouvelles 
collaborations. 
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Les Spécifications Formelles : 
leur impact au cours des différentes étapes 
du cycle de vie du logiciel. 





RIS : veille technologique, 
un auditoire nombreux et 
attentif. 


Marie-Claude Gaudel, directrice 
du LRI-Orsay, conférence Génie Logiciel. 
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Les projets communautaires 


Les programmes de développement 
technologique lancés par 

la Communauté Européenne, 
notamment ESPRIT, le plus 
important, ont offert de nouveaux 
modes d’actions favorisant 

le rapprochement RECHERCHE- 
INDUSTRIE. 


Ces projets, par la dimension 
européenne des collaborations et la 
présence d’industriels, ont donné aux 
équipes de recherche impliquées, une 
ouverture nouvelle et imposé un 
champ d'investigation plus large avec 
une prise en compte des réalités près 
du terrain industriel. Ils ont fortement 
influencé le contenu des travaux 

des chercheurs, leurs modes de travail 
et offert de nouveaux moyens pour 
conforter et valider les orientations 
qu'ils avaient choisies. 


Ils ont permis en outre aux équipes 
de recherche contractantes de trouver 
de nouvelles sources de financement 
et ainsi de planifier leurs travaux sur 
une durée qui devait leur assurer de 
meilleurs résultats. 


Les équipes du GRECO 
PROGRAMMATION sont engagées 
nombreuses dans ces actions 
communautaires, mais les projets 
présentés ici n’en rendent compte que 
de façon partielle. En effet, au 
moment de la préparation de ce 
document, plusieurs propositions 
en cours de soumission en réponse 
à l'appel d’offres ESPRIT 2 devraient 
donner lieu à de nouveaux contrats. 


PROJETS ESPRIT 


ALPES EQUIPE MODAL 

page 28 

ALPES (Advanced Logic Programming En- 
vironmentS) est destiné à définir et implé- 
menter un environnement de prog'amma- 
tion pour Prolog. Dans Parchitecture à trois 
niveaux de cet environnement (programme, 
compilation, exécution), l’équipe Modal 
intervient plutôt au niveau statique du pro- 
gramme, Cela regroupe la définition de pri- 
mitives de contrôle de types et coercitions, 
de mise au point, etc. 

partenaires : CRIL, Bull, Enidata (Bologne 
Italie), LRI Orsay, Université de Lisbonne, 
Technische Universitaet Muenchen (Mu- 
nich RFA). 


CHAMELEON 

EQUIPE ARCHITECTURE 

page 81 

Ce projet vise à étudier et réaliser “gracieuse- 
ment” la migration dynamique de processus 
dans un réseau de machines et systèmes 
hétérogènes, Les méthodes utilisées sont 
aussi bien de nature interprétative que com- 
pilatoire, en particulier le projet s’attache à 
décrire précisément {a sémantique des 
appels systèmes de plusieurs systèmes diffé- 
rents afin de pouvoir les traduire automati- 
quement d’un système vers un autre, 
partenaires : Non Standard Logics, Delphi 
(Italie), Harlequin (Cambridge, Grande- 
Bretagne). 


COCOS EQUIPE ATTRISEM 

page 26 

COCOS (COmponents for future COmputing 
Systems) étudie une architecture ouverte 
pour une station de travail à usage bureauti- 
que ainsi que les composants s’y intégrant. 
L'équipe participe surtout aux tâches autour 
du langage PARLOG de programmation logi- 
que parallèle, Ainsi, PARLOG est implé- 
menté sur une base matérielle associant un 
processeur symbolique à un processeur clas- 
sique (68020 ou RISC). Enfin, de nouveaux 
concepts comme la programmation orientée 
objet sont développés avec PARLOG. 


FOR-ME-TOO EQUIPE LPG 

page 41 

FOR-ME-TOO (FORmalism - MEthods - 
TOOIs: Software development based on and 
supporting the concept ofreusability ofcom- 
ponents) est proche de Replay. L'équipe 
LPG a défini un ensemble de primitives de 
structuration algébrique ayant servi à la réali- 
sation d’un gestionnaire de fenêtres, Ces pri- 
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mitives peuvent être considérées comme 
une extension du projet LPG dans le sens 
d’une programmation par composants, avec 
structuration horizontale et verticale. 

partenaires : Syseca, Division RTT d’Infigenie. 


PROLOG EQUIPE PROLOG-IT 

page 66 

Le GIA est engagé dans le projet P1219 “Fur- 
ther development of Prolog and its valida- 
tion by KBS in technical areas”, Il s’agit con- 
crètement de réaliser un système expert en 
diagnostic de panne de voitures grâce à une 
version améliorée de Prolog II. Le GIA devra 
en particulier ajouter à la version existante 
une arithmétique complète et l'intégration 
des contraintes numériques à l’unification. 
Par ailleurs, les deux industriels allemands 
synthétiseront une base de connaissances et 
les règles d’expertise à partir de leur savoir- 
faire dans le domaine, Ces points serviront 
de base au futur système. 

partenaires : ProloglA, Daimler-Bentz (Stutt- 
gart RFA), Bosch (RFA). 


RAGTIME EQUIPE MANENS 

page 60 

RagTime (Reusable components and Auto- 
mated Generation of real-TIME implemen- 
tations) cherche à construire un logiciel de 
haut niveau pour la spécification de systè- 
mes intégrant temps-réel et parallélisme. Le 
groupe Manens participe à la préparation de 
ce projet ESPRIT-2 et devrait intervenir 
autour du langage S3L : Comparaison à 
SETL, évaluation de implémentation, inté- 
gration de possibilités de concurrence vers la 
programmation relationnelle, 

partenaires : Thomson-CSF. 


REPLAY EQUIPE SPRAC & LPG 

page 46 & page 41 

Replay est le successeur de Tool-Use cité 
plus bas. Son rôle est d'estimer l'impact des 
outils de manipulation du développement 
dans un contexte de réutilisation du logiciel. 
Deux pôles sont privilégiés : la composition 
de plans de développement avecentre autres 
les aspects réutilisation descendante et 
assemblage ascendant. 

Le contrôle permanent des propriétés assu- 
rant la vérification des contraintes opéra- 
tionnelles du cahier des charges. 
partenaires : CISI-Engenierie, UCL (Louvain 
Belgique), Alpha-SAI (Athènes Grèce), CRI 
A/S (Copenhague Danemark), E2S (Bel- 
gique). 


Les projets communautaires 


SOMIW EQUIPE LANGAGES-OBJETS 
page 52 

SOMIW (Secure Open Multimedia Integrated 
Workstation) sera une station de travail 
bureautique d’une puissance entre un PC-AT 
et un Sun. Le groupe Langages-Objets inter- 
vient dansle projet Somiw par le biais de Phi- 
lippe Gaudron qui réalise le système SOS à 
objets répartis. Ce travail, fortement basé sur 
C++, a engendré un éditeur de liens dynami- 
que permettant la migration d'objets. SOS est 


ainsi envisagé comme plate-forme d’expéri-. 


mentation d’un univers multimédia distri- 
bué reposant sur l'approche objet. 
partenaires : Bull 


TIPE EQUIPE EURECA 
page 20 


TIPE représente les concepts Types, Inheri- 
tance, Polymorphism & Equalities. Ce projet 
qui sera soumis au programme ESPRIT-2 est 
encore en cours de définition. Il visera à étu- 
dier et réaliser un environnement de pro- 
grammation sûr, destiné au développement 
d’applications d’aéronautique ou à haut ris- 
que. L’environnement de preuve intégrera 
en particulier un langage de spécification 
puissant et exécutable. 


TOOL-USE EQUIPE SPRAC 

page 46 

Ce projet vise à fournir une assitance active à 
la conception, à l'implémentation et lPévolu- 
tion du logiciel. Cela passe par quatre points 
fondamentaux : étude et compréhension des 
méthodes de développement, formalisation 
du processus de développement, définition 
et réalisation d’un langage de développe- 
ment (DEVA), réalisation de Penvironne- 
ment support. Actuellement, DEVA permet 
de spécifier des développements simples et 
un prototype est en cours d'achèvement. 
partenaires : CISI-Engenierie, Trinity College 
(Dublin Irlande), Generics (Irlande), UCL 
(Louvain Belgique), GMD (Karlsruhe RFA), 
Biomatic (Freiburg RFA) 


04 ÉQUIPE RANK XEROX FRANCE, 
P. Cointe, M. Politis ; 
Contractant principal : Bull. 


Le projet 04 aura pour point de départ Putili- 
sation des postes de travail et Pétat de l’art de 
la recherche dans le domaine en 88. Les 
travaux seront menés de 1989 à 1993 en 
intégrant les développements issus de la 
pratique et de la recherche. Les résultats 
conduiront à un poste de travail bureautique 
multi-média à l'usage des non-informa- 
ticiens. 

Pour ce faire, il sera fait un grand usage de la 
programmation par objets (voir page 79) et 


plus particulièrement des systèmes Com- 
monLisp-CLOS et BETA. 


PROJET RACE 


SPECS ÉQUIPE OASIS DU CNET 

page 44 

L'équipe participe dans le cadre de la phase 
principale du programme européen RACE, 
au projet SPECS concernant les environne- 
ments de spécification pour les systèmes 
de communication. Ces travaux ont pour 
échéance fin 1992. 


PROJET COMETT 


EQUIPE MAIDAY 

page 38 

Une mise en œuvre des outils développés 
par l’équipe du projet MAIDAY est à l'étude 
au plan industriel dans le cadre de la partici- 
pation du projet européen COMETT. 
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Ada (langage de programmation) 
algorithmes (théorie des) 
algorithmes d’automates 
algorithmes de codes 
algorithmes de mots 

algorithmes de tri 

algorithmes parallèles 

ALOG (langage d’acteurs) 
analyse d’algorithmes 
apprentissage (classification de concepts) 
architecture multiprocesseurs 
architecture parallèle 
architecture parallèle synchrone 
architecture pyramidale 
ASSPEGIQUE (environnement/ 
atelier de génie logiciel) 

attributs sémantiques 


bases de données 
bases de données projet 
bases de données pour génie logiciel 


C++ (couche objet pour langage C) 

calcul des constructions 

calcul formel 

calcul symbolique 

CAML (langage fonctionnel) 

CENTAUR (sémantique dénotationnelle) 
Cigale (ASSPEGIQUE) 

cinquième génération (langages de) 
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